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.026 / U:90.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site