LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mike Travis <travis@sgi.com>
To: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	mingo@elte.hu, Christoph Lameter <clameter@sgi.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses
Date: Fri, 18 Jan 2008 10:49:00 -0800	[thread overview]
Message-ID: <4790F49C.3050002@sgi.com> (raw)
In-Reply-To: <200801181933.05662.ak@suse.de>

Andi Kleen wrote:
> On Friday 18 January 2008 19:30:16 travis@sgi.com wrote:
>> Provide a means to trap usages of per_cpu map variables before
>> they are setup.  Define CONFIG_DEBUG_PER_CPU_MAPS to activate.
> 
> Are you sure that debug option is generally useful enough
> to merge? It seems very specific to your patchkit, but I'm not
> sure it would be worth carrying forever in the kernel.
> 
> Better would be probably to just unmap those areas anyways.
> 
> -Andi

I thought for a round of testing it'd be worthwhile, particularly
testing randconfig.  The next version of percpu changes are coming
soon and I can remove them then.  Ideally, you are right, it'd
be nice to not have the percpu memory mapped for processors that are
not present.

One thing that comes into play is that (soon) the boot_pda will be
in the per_cpu area and it's maintained for all "possible" cpus as
it keeps track of some info on "off-lined" cpus.  What I was thinking
is that perhaps no memory is allocated (and mapped) until a cpu
becomes not only possible, but probable.  This means that until a
cpu is brought online, or discovered via ACPI, then there is no percpu
area and access to an invalid percpu area causes a kernel fault.

Thanks,
Mike

  reply	other threads:[~2008-01-18 18:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-18 18:30 [PATCH 0/5] x86: Reduce memory usage for large count NR_CPUs fixup travis
2008-01-18 18:30 ` [PATCH 1/5] x86: Change size of node ids from u8 to u16 fixup travis
2008-01-18 19:56   ` Jan Engelhardt
2008-01-18 19:59     ` Mike Travis
2008-01-19  4:03   ` Yinghai Lu
2008-01-19  4:36     ` David Rientjes
2008-01-19  4:43       ` Yinghai Lu
2008-01-19  5:17         ` David Rientjes
2008-01-19  6:20           ` Yinghai Lu
2008-01-19 21:25       ` Mike Travis
2008-01-19 22:33         ` David Rientjes
2008-01-20  0:41           ` Mike Travis
2008-01-20  1:31             ` Yinghai Lu
2008-01-20  6:22             ` David Rientjes
2008-01-18 18:30 ` [PATCH 2/5] x86: Change NR_CPUS arrays in numa_64 fixup travis
2008-01-18 18:30 ` [PATCH 3/5] x86: Change bios_cpu_apicid to percpu data variable fixup travis
2008-01-18 18:30 ` [PATCH 4/5] x86: Add config variables for SMP_MAX travis
2008-01-18 20:04   ` Ingo Oeser
2008-01-18 20:10     ` Christoph Lameter
2008-01-18 20:14     ` Mike Travis
2008-01-18 20:36       ` Andi Kleen
2008-01-18 20:48         ` Mike Travis
2008-01-18 21:02         ` [PATCH 4/5] x86: Add config variables for SMP_MAX II Andi Kleen
2008-01-18 20:48       ` [PATCH 4/5] x86: Add config variables for SMP_MAX Ingo Molnar
2008-01-18 20:55         ` Mike Travis
2008-01-18 20:58           ` Andi Kleen
2008-01-28 16:45       ` Paul Jackson
2008-01-28 17:00         ` Andi Kleen
2008-01-18 20:46   ` Ingo Molnar
2008-01-19 14:52   ` Ingo Molnar
2008-01-19 15:15     ` Ingo Molnar
2008-01-19 15:24       ` Ingo Molnar
2008-01-19 21:52         ` Mike Travis
2008-01-19 23:24         ` Mike Travis
2008-01-20  1:14         ` Mike Travis
2008-01-19 21:39     ` Mike Travis
2008-01-18 18:30 ` [PATCH 5/5] x86: Add debug of invalid per_cpu map accesses travis
2008-01-18 18:33   ` Andi Kleen
2008-01-18 18:49     ` Mike Travis [this message]
2008-01-18 18:56     ` Christoph Lameter
2008-01-18 20:49     ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4790F49C.3050002@sgi.com \
    --to=travis@sgi.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).