Re: [PATCH 5/5] proc: export more page flags in /proc/kpageflags
From: Wu Fengguang
Date: Wed Apr 29 2009 - 21:00:56 EST
On Thu, Apr 30, 2009 at 03:13:56AM +0800, Matt Mackall wrote:
> On Wed, 2009-04-29 at 16:05 +0800, Wu Fengguang wrote:
> > On Wed, Apr 29, 2009 at 01:49:21AM +0800, Matt Mackall wrote:
> > > On Tue, 2009-04-28 at 09:09 +0800, Wu Fengguang wrote:
> > > > plain text document attachment (kpageflags-extending.patch)
> > > > Export 9 page flags in /proc/kpageflags, and 8 more for kernel developers.
> > >
> > > My only concern with this patch is it knows a bit too much about SLUB
> > > internals (and perhaps not enough about SLOB, which also overloads
> > > flags).
> >
> > Yup. PG_private=PG_slob_free is not masked because SLOB actually does
> > not set PG_slab at all. I wonder if it's safe to do this change:
> >
> > /* SLOB */
> > - PG_slob_page = PG_active,
> > + PG_slob_page = PG_slab,
> > PG_slob_free = PG_private,
>
> Yep.
OK. I'll do it - for consistency.
> > In the page-types output:
> >
> > flags page-count MB symbolic-flags long-symbolic-flags
> > 0x000800000040 7113 27 ______A_________________P____ active,private
> > 0x000000000040 66 0 ______A______________________ active
> >
> > The above two lines are obviously for SLOB pages. It indicates lots of
> > free SLOB pages. So my question is:
>
> Free here just means partially allocated.
Yes, I realized this when lying in bed ;-)
> > - Do you have other means to get the nr_free_slobs info? (I found none in the code)
> > or
> > - Will exporting the SL*B overloaded flags going to help?
>
> Yes, it's useful.
Thank you. SLUB/SLOB overload different page flags, so it's possible
for user space tools to restore their real meanings - ugly but useful.
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/