lkml.org 
[lkml]   [2007]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Major regression on hackbench with SLUB (more numbers)
On Fri, 21 Dec 2007 23:54:13 +0100
Ingo Molnar <mingo@elte.hu> wrote:

> * Christoph Lameter <clameter@sgi.com> wrote:
>
> > On Fri, 21 Dec 2007, Peter Zijlstra wrote:
> >
> > > BTW, does /proc/slabinfo exist again? I thought we set that as a
> > > requirement for SLUB to be the default and a full replacement for
> > > SLAB.
> >
> > Well the information that would be exposed in /proc/slabinfo would
> > only be faked up stuff from SLUB. The queues that are described in
> > /proc/slabinfo do not exist f.e. (tunables do not make sense) and
> > there are more details available via /sys/kernel/slab.
>
> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it.

That would be really bad.

/proc/slabinfo intimately exposes implementation-specific internals and
strictly speaking should never have been introduced. Obviously that isn't
a _practical_ position, but there are no easy solutions here.

We don't want to have to drag a pile of be-compatible-with-slab gunk along
with us for ever.

> slabtop
> relies on it, people use it every day to monitor memory consumption.

slabtop needs to be changed asap.

Possibly we could look at adding some interrim make-it-look-like-slab hack
into slub.c for a couple of releases but no longer.

If we'd updated slabtop six months ago this issue wouldn't have arisen now.

But we didn't do that. We're quite bad at this sort of thing.


\
 
 \ /
  Last update: 2007-12-22 00:31    [W:0.110 / U:0.312 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site