From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 22:32:00 +0200
> Focus on the slab allocator usage, instrument it, record a trace,
> generate a statistical model that matches, and write a small
> programm/kernel module that has the same allocation pattern. Then verify
> this
On Thu, 2007-10-04 at 17:02 -0400, Chuck Ebbert wrote:
> On 10/04/2007 04:55 PM, David Miller wrote:
> >
> > Anything, I do mean anything, can be simulated using small test
> > programs.
>
> How do you simulate reading 100TB of data spread across 3000 disks,
> selecting 10% of it using some
Patch 2/2
SLUB: Allow foreign objects on the per cpu object lists.
In order to free objects we need to touch the page struct of the page that the
object belongs to. If this occurs too frequently then we could generate a
bouncing
cacheline.
We do not want that to occur too frequently. We can
On Fri, 5 Oct 2007, Jens Axboe wrote:
> It might not, it might. The point is trying to isolate the problem and
> making a simple test case that could be used to reproduce it, so that
> Christoph (or someone else) can easily fix it.
In case there is someone who wants to hack on it: Here is what I
On Fri, 5 Oct 2007, Matthew Wilcox wrote:
> I vaguely remembered something called orasim, so I went looking for it.
> I found http://oss.oracle.com/~wcoekaer/orasim/ which is dated from
> 2004, and I found http://oss.oracle.com/projects/orasimjobfiles/ which
> seems to be a stillborn project. Is
On Fri, Oct 05 2007, Andi Kleen wrote:
> Jens Axboe <[EMAIL PROTECTED]> writes:
> >
> > Writing a small test module to exercise slub/slab in various ways
> > (allocating from all cpus freeing from one, as described) should not be
> > too hard. Perhaps that would be enough to find this performance
On Fri, Oct 05 2007, Matthew Wilcox wrote:
> On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
> > I'd like to second Davids emails here, this is a serious problem. Having
> > a reproducible test case lowers the barrier for getting the problem
> > fixed by orders of magnitude. It's the
On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
> I'd like to second Davids emails here, this is a serious problem. Having
> a reproducible test case lowers the barrier for getting the problem
> fixed by orders of magnitude. It's the difference between the problem
> getting fixed in a
Jens Axboe <[EMAIL PROTECTED]> writes:
>
> Writing a small test module to exercise slub/slab in various ways
> (allocating from all cpus freeing from one, as described) should not be
> too hard. Perhaps that would be enough to find this performance
> discrepancy between slab and slub?
You could
On Fri, Oct 05 2007, Pekka Enberg wrote:
> Hi,
>
> On 10/5/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> > I'd like to second Davids emails here, this is a serious problem. Having
> > a reproducible test case lowers the barrier for getting the problem
> > fixed by orders of magnitude. It's the
Hi,
On 10/5/07, Jens Axboe <[EMAIL PROTECTED]> wrote:
> I'd like to second Davids emails here, this is a serious problem. Having
> a reproducible test case lowers the barrier for getting the problem
> fixed by orders of magnitude. It's the difference between the problem
> getting fixed in a day
On Fri, Oct 05 2007, David Chinner wrote:
> On Thu, Oct 04, 2007 at 03:07:18PM -0700, David Miller wrote:
> > From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2007 17:47:48
> > -0400
> >
> > > On 10/04/2007 05:11 PM, David Miller wrote:
> > > > From: Chuck Ebbert <[EMAIL PROTECTED]> Date:
On Fri, Oct 05 2007, David Chinner wrote:
On Thu, Oct 04, 2007 at 03:07:18PM -0700, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED] Date: Thu, 04 Oct 2007 17:47:48
-0400
On 10/04/2007 05:11 PM, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED] Date: Thu, 04 Oct 2007
Hi,
On 10/5/07, Jens Axboe [EMAIL PROTECTED] wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference between the problem
getting fixed in a day or two
On Fri, Oct 05 2007, Pekka Enberg wrote:
Hi,
On 10/5/07, Jens Axboe [EMAIL PROTECTED] wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference
On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the difference between the problem
getting fixed in a day
On Fri, Oct 05 2007, Matthew Wilcox wrote:
On Fri, Oct 05, 2007 at 08:48:53AM +0200, Jens Axboe wrote:
I'd like to second Davids emails here, this is a serious problem. Having
a reproducible test case lowers the barrier for getting the problem
fixed by orders of magnitude. It's the
Jens Axboe [EMAIL PROTECTED] writes:
Writing a small test module to exercise slub/slab in various ways
(allocating from all cpus freeing from one, as described) should not be
too hard. Perhaps that would be enough to find this performance
discrepancy between slab and slub?
You could
On Fri, Oct 05 2007, Andi Kleen wrote:
Jens Axboe [EMAIL PROTECTED] writes:
Writing a small test module to exercise slub/slab in various ways
(allocating from all cpus freeing from one, as described) should not be
too hard. Perhaps that would be enough to find this performance
On Fri, 5 Oct 2007, Matthew Wilcox wrote:
I vaguely remembered something called orasim, so I went looking for it.
I found http://oss.oracle.com/~wcoekaer/orasim/ which is dated from
2004, and I found http://oss.oracle.com/projects/orasimjobfiles/ which
seems to be a stillborn project. Is
On Fri, 5 Oct 2007, Jens Axboe wrote:
It might not, it might. The point is trying to isolate the problem and
making a simple test case that could be used to reproduce it, so that
Christoph (or someone else) can easily fix it.
In case there is someone who wants to hack on it: Here is what I
Patch 2/2
SLUB: Allow foreign objects on the per cpu object lists.
In order to free objects we need to touch the page struct of the page that the
object belongs to. If this occurs too frequently then we could generate a
bouncing
cacheline.
We do not want that to occur too frequently. We can
On Thu, 2007-10-04 at 17:02 -0400, Chuck Ebbert wrote:
On 10/04/2007 04:55 PM, David Miller wrote:
Anything, I do mean anything, can be simulated using small test
programs.
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it using some criterion,
From: Peter Zijlstra [EMAIL PROTECTED]
Date: Fri, 05 Oct 2007 22:32:00 +0200
Focus on the slab allocator usage, instrument it, record a trace,
generate a statistical model that matches, and write a small
programm/kernel module that has the same allocation pattern. Then verify
this statistical
> On 10/04/2007 07:39 PM, David Schwartz wrote:
> > But this is just a preposterous position to put him in. If there's no
> > reproduceable test case, then why should he care that one
> > program he can't
> > even see works badly? If you care, you fix it.
> People have been trying for years to
On Thu, 4 Oct 2007 19:43:58 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> So there could still be page struct contention left if multiple
> processors frequently and simultaneously free to the same slab and
> that slab is not the per cpu slab of a cpu. That could be addressed
> by
I just spend some time looking at the functions that you see high in the
list. The trouble is that I have to speculate and that I have nothing to
verify my thoughts. If you could give me the hitlist for each of the
3 runs then this would help to check my thinking. I could be totally off
here.
On 10/04/2007 07:39 PM, David Schwartz wrote:
> But this is just a preposterous position to put him in. If there's no
> reproduceable test case, then why should he care that one program he can't
> even see works badly? If you care, you fix it.
>
People have been trying for years to make
David Miller wrote:
> Using an unpublishable benchmark, whose results even cannot be
> published, really stretches the limits of "reasonable" don't you
> think?
>
> This "SLUB isn't ready yet" bullshit is just a shamans dance which
> distracts attention away from the real problem, which is that
On Thu, Oct 04, 2007 at 03:07:18PM -0700, David Miller wrote:
> From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2007 17:47:48
> -0400
>
> > On 10/04/2007 05:11 PM, David Miller wrote:
> > > From: Chuck Ebbert <[EMAIL PROTECTED]> Date: Thu, 04 Oct 2007 17:02:17
> > > -0400
> > >
> > >>
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 04 Oct 2007 17:47:48 -0400
> On 10/04/2007 05:11 PM, David Miller wrote:
> > From: Chuck Ebbert <[EMAIL PROTECTED]>
> > Date: Thu, 04 Oct 2007 17:02:17 -0400
> >
> >> How do you simulate reading 100TB of data spread across 3000 disks,
> >>
On 10/04/2007 05:11 PM, David Miller wrote:
> From: Chuck Ebbert <[EMAIL PROTECTED]>
> Date: Thu, 04 Oct 2007 17:02:17 -0400
>
>> How do you simulate reading 100TB of data spread across 3000 disks,
>> selecting 10% of it using some criterion, then sorting and
>> summarizing the result?
>
> You
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
> Yet here we stand. Christoph is aggressively trying to get slab removed
> from the tree. There is a testcase which shows slub performing worse
> than slab. It's not my fault I can't publish it. And just because I
> can't publish it doesn't mean it
From: Chuck Ebbert <[EMAIL PROTECTED]>
Date: Thu, 04 Oct 2007 17:02:17 -0400
> How do you simulate reading 100TB of data spread across 3000 disks,
> selecting 10% of it using some criterion, then sorting and
> summarizing the result?
You repeatedly read zeros from a smaller disk into the same
On 10/04/2007 04:55 PM, David Miller wrote:
>
> Anything, I do mean anything, can be simulated using small test
> programs.
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it using some criterion, then sorting and summarizing
the result?
-
To unsubscribe from
From: Matthew Wilcox <[EMAIL PROTECTED]>
Date: Thu, 4 Oct 2007 14:58:12 -0600
> On Thu, Oct 04, 2007 at 01:48:34PM -0700, David Miller wrote:
> > There comes a point where it is the reporter's responsibility to help
> > the developer come up with a publishable test case the developer can
> > use
On Thu, Oct 04, 2007 at 01:55:37PM -0700, David Miller wrote:
> Anything, I do mean anything, can be simulated using small test
> programs. Pointing at a big fancy machine with lots of storage
> and disk is a passive aggressive way to avoid the real issues,
> in that nobody is putting forth the
On Thu, Oct 04, 2007 at 01:48:34PM -0700, David Miller wrote:
> There comes a point where it is the reporter's responsibility to help
> the developer come up with a publishable test case the developer can
> use to work on fixing the problem and help ensure it stays fixed.
That's a lot of effort.
From: [EMAIL PROTECTED] (Matthew Wilcox)
Date: Thu, 4 Oct 2007 12:28:25 -0700
> On Thu, Oct 04, 2007 at 10:49:52AM -0700, Christoph Lameter wrote:
> > Finally: Is there some way that I can reproduce the tests on my machines?
>
> As usual for these kinds of setups ... take a two-CPU machine, 64GB
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Thu, 4 Oct 2007 10:50:46 -0700
> Ok every time something says anything not 100% positive about SLUB you
> come back with "but it's fixed in the next patch set"... *every time*.
I think this is partly Christoph subconsciously venting his
On Thu, Oct 04, 2007 at 12:05:35PM -0700, Christoph Lameter wrote:
> > > Was the page allocator pass through patchset
> > > separately applied as I requested?
> >
> > I don't believe so. Suresh?
>
> If it was a git pull then the pass through was included and never taken
> out.
It was a git
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
> We have three runs, all with 2.6.23-rc3 plus the patches that Suresh
> applied from 20070922. The first run is with slab. The second run is
> with SLUB and the third run is SLUB plus the tuning parameters you
> recommended.
There was quite a bit of
On Thu, Oct 04, 2007 at 10:49:52AM -0700, Christoph Lameter wrote:
> I was not aware of that. Would it be possible for you to summarize all the
> test data that you have right now about SLUB vs. SLAB with the patches
> listed? Exactly what kernel version and what version of the per cpu
>
On Thu, 2007-10-04 at 10:50 -0700, Arjan van de Ven wrote:
> On Thu, 4 Oct 2007 10:38:15 -0700 (PDT)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
>
> > Yeah the fastpath vs. slow path is not the issue as Siddha and I
> > concluded earlier. Seems that we are mainly seeing cacheline bouncing
On Thu, 4 Oct 2007, Arjan van de Ven wrote:
> Ok every time something says anything not 100% positive about SLUB you
> come back with "but it's fixed in the next patch set"... *every time*.
All I ask that people test the fixes that have been out there for the
known issues. If there are
On Thu, 4 Oct 2007 10:38:15 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Yeah the fastpath vs. slow path is not the issue as Siddha and I
> concluded earlier. Seems that we are mainly seeing cacheline bouncing
> due to two cpus accessing meta data in the same page struct. The
>
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
> > Yeah the fastpath vs. slow path is not the issue as Siddha and I concluded
> > earlier. Seems that we are mainly seeing cacheline bouncing due to two
> > cpus accessing meta data in the same page struct. The patches in
> > MM that are scheduled to
On Thu, Oct 04, 2007 at 10:38:15AM -0700, Christoph Lameter wrote:
> On Thu, 4 Oct 2007, Matthew Wilcox wrote:
>
> > So, on "a well-known OLTP benchmark which prohibits publishing absolute
> > numbers" and on an x86-64 system (I don't think exactly which model
> > is important), we're seeing
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
> So, on "a well-known OLTP benchmark which prohibits publishing absolute
> numbers" and on an x86-64 system (I don't think exactly which model
> is important), we're seeing *6.51%* performance loss on slub vs slab.
> This is with a 2.6.23-rc3 kernel.
On Thu, Oct 04, 2007 at 10:38:15AM -0700, Christoph Lameter wrote:
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
So, on a well-known OLTP benchmark which prohibits publishing absolute
numbers and on an x86-64 system (I don't think exactly which model
is important), we're seeing *6.51%*
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
Yeah the fastpath vs. slow path is not the issue as Siddha and I concluded
earlier. Seems that we are mainly seeing cacheline bouncing due to two
cpus accessing meta data in the same page struct. The patches in
MM that are scheduled to be
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
So, on a well-known OLTP benchmark which prohibits publishing absolute
numbers and on an x86-64 system (I don't think exactly which model
is important), we're seeing *6.51%* performance loss on slub vs slab.
This is with a 2.6.23-rc3 kernel. Tuning
On Thu, 4 Oct 2007, Arjan van de Ven wrote:
Ok every time something says anything not 100% positive about SLUB you
come back with but it's fixed in the next patch set... *every time*.
All I ask that people test the fixes that have been out there for the
known issues. If there are remaining
On Thu, 4 Oct 2007 10:38:15 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
Yeah the fastpath vs. slow path is not the issue as Siddha and I
concluded earlier. Seems that we are mainly seeing cacheline bouncing
due to two cpus accessing meta data in the same page struct. The
patches
On Thu, Oct 04, 2007 at 10:49:52AM -0700, Christoph Lameter wrote:
I was not aware of that. Would it be possible for you to summarize all the
test data that you have right now about SLUB vs. SLAB with the patches
listed? Exactly what kernel version and what version of the per cpu
patches
On Thu, 2007-10-04 at 10:50 -0700, Arjan van de Ven wrote:
On Thu, 4 Oct 2007 10:38:15 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
Yeah the fastpath vs. slow path is not the issue as Siddha and I
concluded earlier. Seems that we are mainly seeing cacheline bouncing
due to
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
We have three runs, all with 2.6.23-rc3 plus the patches that Suresh
applied from 20070922. The first run is with slab. The second run is
with SLUB and the third run is SLUB plus the tuning parameters you
recommended.
There was quite a bit of
On Thu, Oct 04, 2007 at 12:05:35PM -0700, Christoph Lameter wrote:
Was the page allocator pass through patchset
separately applied as I requested?
I don't believe so. Suresh?
If it was a git pull then the pass through was included and never taken
out.
It was a git pull from the
From: Arjan van de Ven [EMAIL PROTECTED]
Date: Thu, 4 Oct 2007 10:50:46 -0700
Ok every time something says anything not 100% positive about SLUB you
come back with but it's fixed in the next patch set... *every time*.
I think this is partly Christoph subconsciously venting his
frustration that
From: [EMAIL PROTECTED] (Matthew Wilcox)
Date: Thu, 4 Oct 2007 12:28:25 -0700
On Thu, Oct 04, 2007 at 10:49:52AM -0700, Christoph Lameter wrote:
Finally: Is there some way that I can reproduce the tests on my machines?
As usual for these kinds of setups ... take a two-CPU machine, 64GB
of
On Thu, Oct 04, 2007 at 01:48:34PM -0700, David Miller wrote:
There comes a point where it is the reporter's responsibility to help
the developer come up with a publishable test case the developer can
use to work on fixing the problem and help ensure it stays fixed.
That's a lot of effort. Is
On Thu, Oct 04, 2007 at 01:55:37PM -0700, David Miller wrote:
Anything, I do mean anything, can be simulated using small test
programs. Pointing at a big fancy machine with lots of storage
and disk is a passive aggressive way to avoid the real issues,
in that nobody is putting forth the
From: Matthew Wilcox [EMAIL PROTECTED]
Date: Thu, 4 Oct 2007 14:58:12 -0600
On Thu, Oct 04, 2007 at 01:48:34PM -0700, David Miller wrote:
There comes a point where it is the reporter's responsibility to help
the developer come up with a publishable test case the developer can
use to work
On 10/04/2007 04:55 PM, David Miller wrote:
Anything, I do mean anything, can be simulated using small test
programs.
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it using some criterion, then sorting and summarizing
the result?
-
To unsubscribe from
From: Chuck Ebbert [EMAIL PROTECTED]
Date: Thu, 04 Oct 2007 17:02:17 -0400
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it using some criterion, then sorting and
summarizing the result?
You repeatedly read zeros from a smaller disk into the same amount
On Thu, 4 Oct 2007, Matthew Wilcox wrote:
Yet here we stand. Christoph is aggressively trying to get slab removed
from the tree. There is a testcase which shows slub performing worse
than slab. It's not my fault I can't publish it. And just because I
can't publish it doesn't mean it
On 10/04/2007 05:11 PM, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED]
Date: Thu, 04 Oct 2007 17:02:17 -0400
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it using some criterion, then sorting and
summarizing the result?
You repeatedly
From: Chuck Ebbert [EMAIL PROTECTED]
Date: Thu, 04 Oct 2007 17:47:48 -0400
On 10/04/2007 05:11 PM, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED]
Date: Thu, 04 Oct 2007 17:02:17 -0400
How do you simulate reading 100TB of data spread across 3000 disks,
selecting 10% of it
On Thu, Oct 04, 2007 at 03:07:18PM -0700, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED] Date: Thu, 04 Oct 2007 17:47:48
-0400
On 10/04/2007 05:11 PM, David Miller wrote:
From: Chuck Ebbert [EMAIL PROTECTED] Date: Thu, 04 Oct 2007 17:02:17
-0400
How do you simulate
David Miller wrote:
Using an unpublishable benchmark, whose results even cannot be
published, really stretches the limits of reasonable don't you
think?
This SLUB isn't ready yet bullshit is just a shamans dance which
distracts attention away from the real problem, which is that a
On 10/04/2007 07:39 PM, David Schwartz wrote:
But this is just a preposterous position to put him in. If there's no
reproduceable test case, then why should he care that one program he can't
even see works badly? If you care, you fix it.
People have been trying for years to make reproducible
I just spend some time looking at the functions that you see high in the
list. The trouble is that I have to speculate and that I have nothing to
verify my thoughts. If you could give me the hitlist for each of the
3 runs then this would help to check my thinking. I could be totally off
here.
On Thu, 4 Oct 2007 19:43:58 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
So there could still be page struct contention left if multiple
processors frequently and simultaneously free to the same slab and
that slab is not the per cpu slab of a cpu. That could be addressed
by
On 10/04/2007 07:39 PM, David Schwartz wrote:
But this is just a preposterous position to put him in. If there's no
reproduceable test case, then why should he care that one
program he can't
even see works badly? If you care, you fix it.
People have been trying for years to make
74 matches
Mail list logo
