Messages in this thread | | | Date | Thu, 17 Apr 2008 11:46:06 +0200 | From | Ingo Molnar <> | Subject | Re: [v2.6.26] what's brewing in x86.git for v2.6.26 |
| |
* 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?
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)
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.] Or we could do a CONFIG_KMEMCHECK=y only page->flags_debug.
Ingo
| |