From: Andrew Morton <akpm@linux-foundation.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [v2.6.26] what's brewing in x86.git for v2.6.26
Date: Thu, 17 Apr 2008 03:06:11 -0700 [thread overview]
Message-ID: <20080417030611.af071ac3.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080417094606.GA19607@elte.hu>
On Thu, 17 Apr 2008 11:46:06 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > > you mean kmemcheck? Yes, that's planned. We've been working 4 months
> > > non-stop on kmemcheck to make it mergeable and usable, it's at
> > > version 7 right now, and it caught a handful of real bugs already
> > > (such as 63a7138671c - unfortunately not credited in the log to
> > > kmemcheck). But because it touches SLUB (because it has to - and
> > > they are acked by Pekka) i never had the chance to move it into the
> > > for-akpm branch.
> >
> > Does it really really really need to consume one of our few remaining
> > page flags? We'll be in a mess when we run out.
>
> well AFAICS the shortage really mostly affects 32-bit platforms. And
> there we've got 19 bits used, out of 23 available, right?
Unfortunately the answer to that question is surprisingly hard to generate
and it probably has changed over time. Christoph sat down and worked it
all out a few months ago.
One surprising problem is ia64 which uses (or used to use?) basically all
of the upper 32-bits.
> whether we track a page or not is rather fundamental to kmemcheck, i
> dont see any easy way to get rid of that usage. (and since kmemcheck is
> a transparent add-on, i dont see any obvious other candidate like
> page->private either - all those fields might be utilized)
oooh yeah. We've squeezed blood out of the pageframe.
> if we run out of that in the future: the high bits get used by sparse
> section and numa node ID bits, worst-case we could live with restricting
> the max number of NUMA nodes on 32-bit from 64 to 32? [NUMA on 32-bit is
> an afterthought anyway.]
Yes, I think it's only NUMAQ and one of the old IBM machines. I don't
think numaq ever went beyond 8 nodes. superh is (or will) use NUMA, but
surely not with many nodes.
> Or we could do a CONFIG_KMEMCHECK=y only
> page->flags_debug.
Yes, that'd be OK. We could do that now, or just pop a comment in there.
next prev parent reply other threads:[~2008-04-17 10:09 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-16 20:23 [v2.6.26] what's brewing in x86.git for v2.6.26 Ingo Molnar
2008-04-16 20:37 ` Roland Dreier
2008-04-16 22:18 ` Suresh Siddha
2008-04-16 20:50 ` Andi Kleen
2008-04-17 10:06 ` Alexander van Heukelum
2008-04-17 10:51 ` Andi Kleen
2008-04-17 13:33 ` Alexander van Heukelum
2008-04-18 8:38 ` Ingo Molnar
2008-04-18 10:51 ` Andi Kleen
2008-04-17 7:25 ` Andrew Morton
2008-04-17 7:45 ` Pekka Enberg
2008-04-17 8:20 ` Andrew Morton
2008-04-17 8:32 ` Pekka J Enberg
2008-04-17 8:34 ` Pekka Enberg
2008-04-17 8:40 ` Ingo Molnar
2008-04-17 8:42 ` Andrew Morton
2008-04-17 11:49 ` Christoph Hellwig
2008-04-17 11:56 ` Ingo Molnar
2008-04-17 18:01 ` Andrew Morton
2008-04-17 18:51 ` Ingo Molnar
2008-04-17 19:57 ` Andrew Morton
2008-04-17 20:18 ` Ingo Molnar
2008-04-18 9:33 ` Tomasz Kłoczko
2008-04-18 9:42 ` Ingo Molnar
2008-04-17 8:14 ` Andrew Morton
2008-04-17 8:57 ` Avi Kivity
2008-04-17 10:32 ` Johannes Weiner
2008-04-17 10:50 ` Andrew Morton
2008-04-17 11:49 ` Christoph Hellwig
2008-04-17 17:36 ` Andrew Morton
2008-04-17 8:30 ` Ingo Molnar
2008-04-17 8:40 ` Andrew Morton
2008-04-17 8:45 ` David Miller
2008-04-17 8:54 ` Andrew Morton
2008-04-17 8:56 ` Andrew Morton
2008-04-17 9:19 ` David Miller
2008-04-17 9:33 ` Andrew Morton
2008-04-17 9:06 ` Ingo Molnar
2008-04-17 9:18 ` Andrew Morton
2008-04-17 9:30 ` Ingo Molnar
2008-04-17 9:36 ` Andrew Morton
2008-04-17 9:46 ` Ingo Molnar
2008-04-17 10:06 ` Andrew Morton [this message]
2008-04-17 10:11 ` Andi Kleen
2008-04-17 10:18 ` Andrew Morton
2008-04-17 10:29 ` Andi Kleen
2008-04-17 10:19 ` Pekka Enberg
2008-04-17 10:33 ` Andrew Morton
2008-04-17 10:38 ` Ingo Molnar
2008-04-17 10:42 ` Pekka Enberg
2008-04-18 11:12 ` Nick Piggin
2008-04-17 14:01 ` Arjan van de Ven
2008-04-17 15:26 ` Ingo Molnar
2008-04-18 12:41 ` Ingo Molnar
2008-04-17 10:41 ` Pekka Enberg
2008-04-17 18:47 ` Vegard Nossum
2008-04-17 19:27 ` Ingo Molnar
2008-04-17 19:35 ` Ingo Molnar
2008-04-17 19:39 ` Vegard Nossum
2008-04-17 19:43 ` Andrew Morton
2008-04-17 20:39 ` Vegard Nossum
2008-04-17 20:55 ` Andrew Morton
2008-04-17 9:53 ` Andrew Morton
2008-04-17 7:48 ` Andrew Morton
2008-04-18 6:27 ` Andrew Morton
2008-04-18 6:38 ` David Miller
2008-04-18 7:47 ` Ingo Molnar
2008-04-18 8:00 ` Andrew Morton
2008-04-18 8:11 ` Christoph Hellwig
2008-04-18 8:18 ` David Miller
2008-04-18 12:48 ` 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=20080417030611.af071ac3.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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