[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1199314218.4497.109.camel@cinder.waste.org>
Date: Wed, 02 Jan 2008 16:50:18 -0600
From: Matt Mackall <mpm@...enic.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Pekka Enberg <penberg@...helsinki.fi>,
Hugh Dickins <hugh@...itas.com>, Ingo Molnar <mingo@...e.hu>,
Andi Kleen <andi@...stfloor.org>,
Christoph Lameter <clameter@....com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo
On Wed, 2008-01-02 at 11:35 -0800, Linus Torvalds wrote:
>
> On Wed, 2 Jan 2008, Pekka Enberg wrote:
> >
> > I already sent the remaining bits to Linus but this looks much
> > cleaner. Thanks Hugh!
> >
> > Acked-by: Pekka Enberg <penberg@...helsinki.fi>
>
> Actually, I'd much rather just do this instead (on top of your patch)
>
> It just creates a new CONFIG_SLABINFO that automatically has the right
> dependencies (ie depends on PROC being on, and either SLAB or SLUB), and
> then both SLAB and SLUB just have the exact same interfaces.
>
> Which means that SLOB could also trivially implement the same thing, with
> no new #ifdef'fery or other crud.
Except SLOB's emulation of slabs is so thin, it doesn't have the
relevant information. We have a very small struct kmem_cache, which I
suppose could contain a counter. But we don't have anything like the
kmalloc slabs, so you'd only be getting half the picture anyway.
The output of slabtop would simply be misleading because there are no
underlying "slabs" in the first place.
--
Mathematics is the supreme nostalgia of our time.
--
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