> Yeah, unfortunately, querying to find out how much memory is being
> used by which parts of the system is something which I think needs to
> be more than just a debugging feature. One could argue that "vmstat",
slabinfo is about querying kernel internals and requiring stable
and permanent inter
On Tue, Dec 25, 2007 at 04:34:18AM +0100, Andi Kleen wrote:
> > And is /sys/slab
> > guaranteed to be a stable and permanent interface if the SLAB
>
> Debugging feature and "stable and permanent" just don't
> fit together. It's like requesting stable and permanent
> sysrq output.
Yeah, unfortuna
On 23/12/2007, Karol Swietlicki <[EMAIL PROTECTED]> wrote:
> On 22/12/2007, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > A manpage for slabinfo would be useful though. Anybody
> > volunteering to write one?
> >
> > -Andi
>
> That would be me.
> I'm a newbie and never wrote a man page before, so it wil
On Fri, 28 Dec 2007, Ingo Molnar wrote:
>
> or if sysfs/kobjects should be scrapped and rewritten, do you have any
> insight into what kind of abstraction could/should replace it? Should we
> go back to procfs and get rid of kobjects altogether? (as it's slowly
> turning into a /proc problem of it
* Al Viro <[EMAIL PROTECTED]> wrote:
> > > So two questions: why isn't -f the default? And is /sys/slab
> >
> > Because it gives misleading output. It displays the name of the
> > first of multiple slabs that share the same storage structures.
>
> Erm... Let me spell it out: current lifetime
On Wed, 26 Dec 2007, Al Viro wrote:
> Erm... Let me spell it out: current lifetime rules are completely broken.
> As it is, create/destroy/create cache sequence will do kobject_put() on
> kfree'd object. Even without people playing with holding sysfs files
> open or doing IO on those.
Urgh. Hel
On Wed, Dec 26, 2007 at 01:31:35PM -0800, Christoph Lameter wrote:
> On Mon, 24 Dec 2007, Theodore Tso wrote:
>
> > So two questions: why isn't -f the default? And is /sys/slab
>
> Because it gives misleading output. It displays the name of the first
> of multiple slabs that share the same stor
On Mon, 24 Dec 2007, Theodore Tso wrote:
> So two questions: why isn't -f the default? And is /sys/slab
Because it gives misleading output. It displays the name of the first
of multiple slabs that share the same storage structures.
--
To unsubscribe from this list: send the line "unsubscribe li
> And is /sys/slab
> guaranteed to be a stable and permanent interface if the SLAB
Debugging feature and "stable and permanent" just don't
fit together. It's like requesting stable and permanent
sysrq output.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, Dec 24, 2007 at 11:21:14AM -0800, Christoph Lameter wrote:
>
> That is why there is a slabinfo tool that does all the nice formatting.
>
> Do a
>
> gcc -o slabinfo Documentation/vm/slabinfo.c
>
> Then run slabinfo instead of doing cat /proc/slabinfo
So two questions: why isn't -f the
On Sat, 22 Dec 2007, Ingo Molnar wrote:
> Christoph, i'd like to apologize for all overly harsh words i said. (and
> i said quite a few :-/ )
Looks like a bad interaction due to overload, vacation, flu epidemic
hitting me and family and also Christmas coming up so that I could not do
my usual
On Sun, 23 Dec 2007, Theodore Tso wrote:
> > tends to work reasonably well for a quick overview, but yes
> > cat was nicer for humans.
>
> Until you start to wonder what the heck :a-136 is:
>
> /sys/slab/:a-136/objs_per_slab: 30
>
> Sigh...
That is why there is a slabinfo tool that doe
On 22 Dec 2007 16:52:56 -0600, Jason L Tibbitts III <[EMAIL PROTECTED]> wrote:
> > "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> IM> Distros will likely pick SLUB if there's no performance worries
> IM> and if it's the default. Fedora rawhide already uses SLUB.
>
> Actually, it seems to m
On Sun, Dec 23, 2007 at 03:15:00PM +0100, Andi Kleen wrote:
> > Same here. In fact, I've always considered that procfs was for
> > humans while sysfs was for tools. sysfs reminds me too much the
> > unexploitable /devices in Solaris. With the proper tools, I think
> > we can do a lot with it, but i
> Same here. In fact, I've always considered that procfs was for
> humans while sysfs was for tools. sysfs reminds me too much the
> unexploitable /devices in Solaris. With the proper tools, I think
> we can do a lot with it, but it's not as intuitive to find the
> proper tools as it was to do "ls"
On Sat, Dec 22, 2007 at 07:59:47PM -0500, Steven Rostedt wrote:
[...]
> But I still scratch my head when ever I need to touch sysfs.
Same here. In fact, I've always considered that procfs was for
humans while sysfs was for tools. sysfs reminds me too much the
unexploitable /devices in Solaris. Wit
[/me sneaks away from the family]
On Sat, 22 Dec 2007, Willy Tarreau wrote:
> On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote:
> > On Sat, 22 Dec 2007, Theodore Tso wrote:
> > > But sometimes when trying to eyeball what is going on, it's a lot
> > > nicer just to use "cat /proc/sl
> "IM" == Ingo Molnar <[EMAIL PROTECTED]> writes:
IM> Distros will likely pick SLUB if there's no performance worries
IM> and if it's the default. Fedora rawhide already uses SLUB.
Actually, it seems to me that not only does Fedora rawhide use SLUB,
but Fedora 8 and 7 use it as well. They do
On Sat, Dec 22, 2007 at 09:50:09PM +, Al Viro wrote:
> On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote:
>
> > > Another problem with using /sys/slab is that it is downright *ugly*.
> > > Why is it for example, that /sys/slab/dentry is a symlink to
> > > ../slab/:a-160?
> >
On 22/12/2007, Andi Kleen <[EMAIL PROTECTED]> wrote:
> A manpage for slabinfo would be useful though. Anybody
> volunteering to write one?
>
> -Andi
That would be me.
I'm a newbie and never wrote a man page before, so it will take a few
days, but I'm bored and out of ideas for any new code for the
On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 22 Dec 2007, Theodore Tso wrote:
> >
> > I have a general problem with things in /sys/slab, and that's just
> > because they are *ugly*. So yes, you can write ugly shell scripts
> > like this to get out information:
>
On Sat, Dec 22, 2007 at 01:00:09PM -0800, Linus Torvalds wrote:
> > Another problem with using /sys/slab is that it is downright *ugly*.
> > Why is it for example, that /sys/slab/dentry is a symlink to
> > ../slab/:a-160?
>
> That's the only really ugly thing there. Otherwise, it's pretty nic
On Sat, 22 Dec 2007, Theodore Tso wrote:
>
> I have a general problem with things in /sys/slab, and that's just
> because they are *ugly*. So yes, you can write ugly shell scripts
> like this to get out information:
[ script deleted ]
> But sometimes when trying to eyeball what is going on, i
As a followup to the thread regarding slabinfo and Andrew's
earlier query about updating slabtop.
watch -n1 slabinfo -S
seems to be a reasonable replacement for slabtop. The only
missing functionality are some hotkeys missing: you have to restart
now to get a different sort order (and to rea
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> I'd also not rely on the fact that only a few people are complaining.
> Most people, even 2.6.24-rc early adopters, still use SLAB because
> early adopters typically use their .23 .config and do a 'make
> oldconfig' - which picks up SLAB. So SLUB use
On Sat, Dec 22, 2007 at 10:01:37AM -0800, Linus Torvalds wrote:
> Well, I do have to admit that I'm not a huge fan of /proc/slabinfo, and
> the fact that there hasn't been a lot of complaints about it going away
> does seem to imply that it wasn't a very important ABI.
>
> I'm the first to stand
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > > It's definitely not a stable ABI. slabtop tends to exit without
> > > any error message on any slabinfo version number increase and I've
> > > seen that happen several times in not so old kernels.
> >
> > so because we sucked in the past we can
On Sat, 22 Dec 2007, Ingo Molnar wrote:
> >
> > It's definitely not a stable ABI. slabtop tends to exit without any
> > error message on any slabinfo version number increase and I've seen
> > that happen several times in not so old kernels.
>
> so because we sucked in the past we can continue
Hi Andi,
On Dec 22, 2007 2:54 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Yeah but then again removing an interface that has been around for
> > ever
>
> Version 2.1 hasn't been around forever and at least slabtop does not
> work over version number changes in my experience.
True but the defaul
> > the rule is very simple: unless you have really, really, really, REALLY
> > good reasons, just dont break stuff.
Could we please drop "kset: move /sys/slab to /sys/kernel/slab" from -mm?
Old slabinfo complains that SLUB_DEBUG is not on and refuses to do anything.
--
To unsubscribe from this l
> Yeah but then again removing an interface that has been around for
> ever
Version 2.1 hasn't been around forever and at least slabtop does not
work over version number changes in my experience.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
Hi,
On Dec 22, 2007 2:37 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Removing an interface that exposes lots of internal details when you
> rewrite the subsystem and those internal details all change seems
> like a good reason to me.
Yeah but then again removing an interface that has been around
> could be offered on SLUB too.
Sure (I argued that in a earlier mail in fact), but it doesn't make
sense to fake into the old slabinfo format.
>
> 'top' isnt critical functionality either like udev, and the ABI does not
> only cover 'critical' functionality. A utility suddenly not working
> g
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it.
> > slabtop relies on it, people use it every day to monitor memory
> > consumption.
>
> It's definitely not a stable ABI. slabtop tends to ex
* David Miller <[EMAIL PROTECTED]> wrote:
> From: Ingo Molnar <[EMAIL PROTECTED]>
> Date: Fri, 21 Dec 2007 23:54:13 +0100
>
> > Really, if your behavior is representative of how our SLAB allocator
> > will be maintained in the future then i'm very, very worried :-(
>
> Actually, to the contrar
On Fri, Dec 21, 2007 at 08:19:42PM -0600, Matt Mackall wrote:
>
> On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote:
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> > > relies on it, people use it every day to monit
On Sat, 2007-12-22 at 01:28 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> > relies on it, people use it every day to monitor memory consumption.
>
> It's definitely not a stable ABI. slabtop tend
On 12/21/2007 07:28 PM, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
>> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
>> relies on it, people use it every day to monitor memory consumption.
>
> It's definitely not a stable ABI. slabtop tends to exit with
Ingo Molnar <[EMAIL PROTECTED]> writes:
> Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. slabtop
> relies on it, people use it every day to monitor memory consumption.
It's definitely not a stable ABI. slabtop tends to exit without any
error message on any slabinfo version number
On 12/21/2007 06:54 PM, Christoph Lameter wrote:
>
> SLUB: Improve hackbench speed
>
> Increase the mininum number of partial slabs to keep around and put
> partial slabs to the end of the partial queue so that they can add
> more objects.
>
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
On Sat, 22 Dec 2007, Ingo Molnar wrote:
> and the regression seems to be largely fixed! Not only is the hackbench
> one fixed, but mmap shows an above-noise improvement as well.
>
> Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Well lets use the version attached to this patch. It turns out that it
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> I'm really getting worried that you are apparently incapable of grasping
> such _SIMPLE_ concepts. Who the heck cares whether you put in zeros or
> whatever else in some of the fields? People use it to know how many
> objects are allocated and sure SLUB
Hi,
On Dec 22, 2007 1:17 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yep, and i ran a quick comparison test on a 2-core box with 3 kernels:
>
> [ best of 5 runs in a row which had a relative jitter of less than 10% ]
>
> MIN v2.6.24.slab v2.6.24.slub v2.6.24.slub.fix
> -
On Fri, 21 Dec 2007 23:54:13 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Christoph Lameter <[EMAIL PROTECTED]> 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
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> And now, can the people who made the problem reports and complained
> about SLUB please test the patch - the ball is now in your court!
yep, and i ran a quick comparison test on a 2-core box with 3 kernels:
[ best of 5 runs in a row which had a r
From: Ingo Molnar <[EMAIL PROTECTED]>
Date: Fri, 21 Dec 2007 23:54:13 +0100
> Really, if your behavior is representative of how our SLAB allocator
> will be maintained in the future then i'm very, very worried :-(
Actually, to the contrary, I actually think Christoph responds to
every problem I'
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> if (unlikely(!prior))
> - add_partial(get_node(s, page_to_nid(page)), page);
> + add_partial_tail(get_node(s, page_to_nid(page)), page);
FYI, this gives me:
mm/slub.c: In function 'kfree':
mm/slub.c:2604: warning:
* Christoph Lameter <[EMAIL PROTECTED]> 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
On Fri, 21 Dec 2007, Christoph Lameter wrote:
> Actually thanks for pointing that out Pekka Here is a patch that takes
> the regression almost completely away (Too much jetlag combined with flu
> seems to have impaired my thinking I should have seen this earlier). I
> still need to run my sla
On Fri, 21 Dec 2007, Christoph Lameter wrote:
>
> Actually thanks for pointing that out Pekka Here is a patch that takes
> the regression almost completely away
Now *this* is what I wanted to see - rather than argue against other
peoples performance regression reports, an actual patch that
On Fri, 21 Dec 2007, Christoph Lameter wrote:
>
> It obviously can replace it and has replaced it for awhile now.
No. If there are 6% performance regressions on TPC-C, then it CAN NOT
replace it!
> Well still SLUB is really superior to SLAB in many ways
>
> - SLUB is performance wise muc
Actually thanks for pointing that out Pekka Here is a patch that takes
the regression almost completely away (Too much jetlag combined with flu
seems to have impaired my thinking I should have seen this earlier). I
still need to run my slab performance tests on this. But hackbench
improves.
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
On Fri, 21 Dec 2007, Pekka Enberg wrote:
> Christoph, did you see Steven's oprofile results for the hackbench
> runs (http://lkml.org/lkml/2007/12/8/198)? Any ideas why we're hitting
> add_partial like crazy?
Hmmm... SLUB is cycling through partial slabs. If it gets fed objects with
a single fre
On Fri, 2007-12-21 at 23:16 +0100, Peter Zijlstra wrote:
> On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote:
> > On Fri, 21 Dec 2007, Linus Torvalds wrote:
> >
> > > If you aren't even motivated to fix the problems that have been reported,
> > > then SLUB isn't even a _potential_ solut
On Fri, 2007-12-21 at 14:11 -0800, Christoph Lameter wrote:
> On Fri, 21 Dec 2007, Linus Torvalds wrote:
>
> > If you aren't even motivated to fix the problems that have been reported,
> > then SLUB isn't even a _potential_ solution, it's purely a problem, and
> > since I am not IN THE LEAST in
On Fri, 21 Dec 2007, Linus Torvalds wrote:
> If you aren't even motivated to fix the problems that have been reported,
> then SLUB isn't even a _potential_ solution, it's purely a problem, and
> since I am not IN THE LEAST interested in having three different
> allocators around, SLUB is going
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> > There are patches pending to address these issues. AFAICT Intel is
> > testing if the regression is still there. There is no way for me to
> > verify what is going on there and there is the constant difficulty of
> > getting detailed information about
Hi,
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > In an extreme case (boot with slub_min_order=9 to get huge page sized
> > slabs) SLUB can win against SLAB:
> >
> > N=10 Time: 0.338 Minimally faster
> > N=20 Time: 0.560 10% faster
> > N=50 Time: 1.353 15% faster
On Dec 21, 2007
On Fri, 21 Dec 2007, Christoph Lameter wrote:
>
> So we have 3 different regimes here (order 0):
[ ... ]
> The regression is contained because:
[ ... ]
Christoph, *NONE* of these arguments matter at all.
The only thing that matters is the simple fact that real-life benchmarks
show that SLUB i
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007, Ingo Molnar wrote:
>
> > and this is not the only regression:
> >
> > http://lkml.org/lkml/2007/10/4/290
> >
> > _6%_ TPC-C regression. That's _a lot_ in TPC-C terms.
> >
> > and just like in this case there were very c
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> and this is not the only regression:
>
> http://lkml.org/lkml/2007/10/4/290
>
> _6%_ TPC-C regression. That's _a lot_ in TPC-C terms.
>
> and just like in this case there were very clear profiles posted. I
> proffer, reading back the whole thread,
On Fri, 21 Dec 2007, Ingo Molnar wrote:
> what's up with this regression? There's been absolutely no activity
> about it in the last 8 days: upstream still regresses, -mm still
> regresses and there are no patches posted for testing.
I added a test that does this 1 alloc N free behavior to the
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > H... Some tests here on an 8p 8G machine:
>
> > In an extreme case (boot with slub_min_order=9 to get huge page sized
> > slabs) SLUB can win against SLAB:
> >
> > N=10 Time: 0.338Minimally
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> H... Some tests here on an 8p 8G machine:
> In an extreme case (boot with slub_min_order=9 to get huge page sized
> slabs) SLUB can win against SLAB:
>
> N=10 Time: 0.338 Minimally faster
> N=20 Time: 0.560 10% faster
> N=50 Time:
Christoph,
Welcome back from your vacation! :-)
On Thu, 13 Dec 2007, Christoph Lameter wrote:
>
> In an extreme case (boot with slub_min_order=9 to get huge page sized
> slabs) SLUB can win against SLAB:
>
> N=10 Time: 0.338 Minimally faster
> N=20 Time: 0.560 10% faster
> N=50 Time: 1
H... Some tests here on an 8p 8G machine:
SLAB
N=10 Time: 0.341
N=20 Time: 0.605
N=50 Time: 1.487
SLUB
N=10 Time: 0.675
N=20 Time: 1.434
N=50 Time: 3.996
So its factor 2 for untuned SLUB. Looking at hackbench: This is a
test that allocates objects that are then consumed by N cpus that th
On Tue, 11 Dec 2007, Ingo Molnar wrote:
> hackbench-10: 1.12 2.99 (166%)
> hackbench-20: 2.04 6.67 (226%)
> hackbench-50: 5.0317.50 (247%)
>
> and hackbench overhead stands out, by a huge margin. Other stuff is
> within measure
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Hackbench seems to show this regression the most. In my tests I didn't
> see much change with kernel builds and such, but the focus was on
> scheduling not memory management. I'll run my kernel tests next for
> both SLAB and SLUB and see if there's
69 matches
Mail list logo
