lkml.org 
[lkml]   [2008]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-04-17 12:09    [W:0.280 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site