[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1192495750.6118.152.camel@localhost>
Date: Mon, 15 Oct 2007 17:49:10 -0700
From: Dave Hansen <haveblue@...ibm.com>
To: Matt Mackall <mpm@...enic.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Rusty Russell <rusty@...tcorp.com.au>,
Jeremy Fitzhardinge <jeremy@...p.org>,
David Rientjes <rientjes@...gle.com>,
Fengguang Wu <wfg@...l.ustc.edu.cn>
Subject: Re: [PATCH 10/11] maps3: add /proc/kpagecount and /proc/kpageflags
interfaces
On Mon, 2007-10-15 at 19:35 -0500, Matt Mackall wrote:
> Perhaps we need something like:
>
> flags = page->flags;
> userflags =
> FLAG_BIT(USER_REFERENCED, flags & PG_referenced) |
> ...
>
> etc. for the flags we want to export. This will let us change to
>
> FLAG_BIT(USER_SLAB, PageSlab(page)) |
>
> if we make a virtual slab bit.
Yeah, that looks like a pretty sane scheme. Do we want to be any more
abstract about it? Perhaps instead of USER_SLAB, it should be
USER_KERNEL_INTERNAL, or USER_KERNEL_USE. The slab itself is going away
as we speak. :)
> And it shows up in grep.
>
> Unfortunately, i386 test_bit is an asm inline and not a macro so we
> can't hope for the compiler to fold up a bunch of identity bit
> mappings for us.
We could also Yeah, that looks like a pretty sane scheme. Do we want to
be any more abstract about it? Perhaps instead of USER_SLAB, it should
be USER_KERNEL_INTERNAL, or USER_KERNEL_USE. The slab itself is going
away as we speak.
For the bits that we want to export, we could also add the unoptimized
access functions for any that don't already have them:
#define __ClearPageReserved(page) __clear_bit(PG_reserved, &(page)->flags)
Anybody changing bit behavior will certainly go check all of the
callers, such as ClearPageReserved() *and* __ClearPageReserved().
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists