On Tuesday 02 October 2007 06:50, Christoph Lameter wrote:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
> > I thought it was slower. Have you fixed the performance regression?
> > (OK, I read further down that you are still working on it but not
> > confirmed yet...)
>
> The problem is with the weird
On Tuesday 02 October 2007 07:01, Christoph Lameter wrote:
> On Sat, 29 Sep 2007, Peter Zijlstra wrote:
> > On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
> > > Really? That means we can no longer even allocate stacks for forking.
> >
> > I think I'm running with 4k stacks...
>
> 4k
On Mon, 2007-10-01 at 14:30 -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Sat, 29 Sep 2007, Andrew Morton wrote:
> >
> > > > atomic allocations. And with SLUB using higher order pages, atomic !0
> > > > order
On Mon, 2007-10-01 at 14:30 -0700, Andrew Morton wrote:
On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Sat, 29 Sep 2007, Andrew Morton wrote:
atomic allocations. And with SLUB using higher order pages, atomic !0
order allocations will be very
On Tuesday 02 October 2007 07:01, Christoph Lameter wrote:
On Sat, 29 Sep 2007, Peter Zijlstra wrote:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
Really? That means we can no longer even allocate stacks for forking.
I think I'm running with 4k stacks...
4k stacks will
On Tuesday 02 October 2007 06:50, Christoph Lameter wrote:
On Fri, 28 Sep 2007, Nick Piggin wrote:
I thought it was slower. Have you fixed the performance regression?
(OK, I read further down that you are still working on it but not
confirmed yet...)
The problem is with the weird way of
On Mon, 1 Oct 2007, Andrew Morton wrote:
> Ah. So the already-dropped
> slub-exploit-page-mobility-to-increase-allocation-order.patch was the
> culprit?
Yes without that patch SLUB will no longer take special action if antifrag
is around.
-
To unsubscribe from this list: send the line
On Mon, 1 Oct 2007 14:38:55 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Oct 2007, Andrew Morton wrote:
>
> > Do slab and slub use the same underlying page size for each slab?
>
> SLAB cannot pack objects as dense as SLUB and they have different
> algorithm to make the
On Mon, 1 Oct 2007, Andrew Morton wrote:
> Do slab and slub use the same underlying page size for each slab?
SLAB cannot pack objects as dense as SLUB and they have different
algorithm to make the choice of order. Thus the number of objects per slab
may vary between SLAB and SLUB and therefore
On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Sep 2007, Andrew Morton wrote:
>
> > > atomic allocations. And with SLUB using higher order pages, atomic !0
> > > order allocations will be very very common.
> >
> > Oh OK.
> >
> > I thought we'd
On Fri, 28 Sep 2007, Mel Gorman wrote:
> Minimally, SLUB by default should continue to use order-0 pages. Peter has
> managed to bust order-1 pages with mem=128MB. Admittedly, it was a really
> hostile workload but the point remains. It was artifically worked around
> with min_free_kbytes (value
On Sat, 29 Sep 2007, Peter Zijlstra wrote:
>
> On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
>
> > Really? That means we can no longer even allocate stacks for forking.
>
> I think I'm running with 4k stacks...
4k stacks will never fly on an SGI x86_64 NUMA configuration given
On Sat, 29 Sep 2007, Andrew Morton wrote:
> > atomic allocations. And with SLUB using higher order pages, atomic !0
> > order allocations will be very very common.
>
> Oh OK.
>
> I thought we'd already fixed slub so that it didn't do that. Maybe that
> fix is in -mm but I don't think so.
>
>
On Fri, 28 Sep 2007, Nick Piggin wrote:
> I thought it was slower. Have you fixed the performance regression?
> (OK, I read further down that you are still working on it but not confirmed
> yet...)
The problem is with the weird way of Intel testing and communication.
Every 3-6 month or so they
On Fri, 28 Sep 2007, Nick Piggin wrote:
I thought it was slower. Have you fixed the performance regression?
(OK, I read further down that you are still working on it but not confirmed
yet...)
The problem is with the weird way of Intel testing and communication.
Every 3-6 month or so they
On Sat, 29 Sep 2007, Andrew Morton wrote:
atomic allocations. And with SLUB using higher order pages, atomic !0
order allocations will be very very common.
Oh OK.
I thought we'd already fixed slub so that it didn't do that. Maybe that
fix is in -mm but I don't think so.
Trying to
On Fri, 28 Sep 2007, Mel Gorman wrote:
Minimally, SLUB by default should continue to use order-0 pages. Peter has
managed to bust order-1 pages with mem=128MB. Admittedly, it was a really
hostile workload but the point remains. It was artifically worked around
with min_free_kbytes (value set
On Sat, 29 Sep 2007, Peter Zijlstra wrote:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
Really? That means we can no longer even allocate stacks for forking.
I think I'm running with 4k stacks...
4k stacks will never fly on an SGI x86_64 NUMA configuration given the
On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Sat, 29 Sep 2007, Andrew Morton wrote:
atomic allocations. And with SLUB using higher order pages, atomic !0
order allocations will be very very common.
Oh OK.
I thought we'd already fixed
On Mon, 1 Oct 2007, Andrew Morton wrote:
Do slab and slub use the same underlying page size for each slab?
SLAB cannot pack objects as dense as SLUB and they have different
algorithm to make the choice of order. Thus the number of objects per slab
may vary between SLAB and SLUB and therefore
On Mon, 1 Oct 2007 14:38:55 -0700 (PDT)
Christoph Lameter [EMAIL PROTECTED] wrote:
On Mon, 1 Oct 2007, Andrew Morton wrote:
Do slab and slub use the same underlying page size for each slab?
SLAB cannot pack objects as dense as SLUB and they have different
algorithm to make the choice of
On Mon, 1 Oct 2007, Andrew Morton wrote:
Ah. So the already-dropped
slub-exploit-page-mobility-to-increase-allocation-order.patch was the
culprit?
Yes without that patch SLUB will no longer take special action if antifrag
is around.
-
To unsubscribe from this list: send the line
On Monday 01 October 2007 06:12, Andrew Morton wrote:
> On Sun, 30 Sep 2007 05:09:28 +1000 Nick Piggin <[EMAIL PROTECTED]>
wrote:
> > On Sunday 30 September 2007 05:20, Andrew Morton wrote:
> > > We can't "run out of unfragmented memory" for an order-2 GFP_KERNEL
> > > allocation in this
On Sun, 30 Sep 2007 05:09:28 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Sunday 30 September 2007 05:20, Andrew Morton wrote:
> > On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin <[EMAIL PROTECTED]>
> wrote:
> > > On Saturday 29 September 2007 19:27, Andrew Morton wrote:
> > > > On Sat, 29
On Sunday 30 September 2007 05:20, Andrew Morton wrote:
> On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin <[EMAIL PROTECTED]>
wrote:
> > On Saturday 29 September 2007 19:27, Andrew Morton wrote:
> > > On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra
> > > <[EMAIL PROTECTED]>
> >
> > wrote:
> > >
On Sunday 30 September 2007 05:20, Andrew Morton wrote:
On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra
[EMAIL PROTECTED]
wrote:
oom-killings, or
On Sun, 30 Sep 2007 05:09:28 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
On Sunday 30 September 2007 05:20, Andrew Morton wrote:
On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
On Sat, 29 Sep 2007
On Monday 01 October 2007 06:12, Andrew Morton wrote:
On Sun, 30 Sep 2007 05:09:28 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
On Sunday 30 September 2007 05:20, Andrew Morton wrote:
We can't run out of unfragmented memory for an order-2 GFP_KERNEL
allocation in this workload. We go and
On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> On Saturday 29 September 2007 19:27, Andrew Morton wrote:
> > On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]>
> wrote:
> > > > oom-killings, or page allocation failures? The latter, one hopes.
> >
On Saturday 29 September 2007 04:41, Christoph Lameter wrote:
> On Fri, 28 Sep 2007, Peter Zijlstra wrote:
> > memory got massively fragemented, as anti-frag gets easily defeated.
> > setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
> > order blocks to stay available, so we
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
> On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]>
wrote:
> > > oom-killings, or page allocation failures? The latter, one hopes.
> >
> > Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
> >
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > oom-killings, or page allocation failures? The latter, one hopes.
>
>
> Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
> (Ubuntu 4.1.2-0ubuntu4)) #27 Tue Sep 18 15:40:35 CEST 2007
>
>
On Sat, 2007-09-29 at 02:01 -0700, Andrew Morton wrote:
> On Sat, 29 Sep 2007 10:53:41 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> >
> > On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
> >
> > > Ah, right, that was the detail... all this lumpy reclaim is useless for
> > >
On Sat, 29 Sep 2007 10:53:41 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
>
> > Ah, right, that was the detail... all this lumpy reclaim is useless for
> > atomic allocations. And with SLUB using higher order pages, atomic !0
> >
On Sat, 29 Sep 2007 10:47:12 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-09-29 at 01:13 -0700, Andrew Morton wrote:
> > On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
> Ah, right, that was the detail... all this lumpy reclaim is useless for
> atomic allocations. And with SLUB using higher order pages, atomic !0
> order allocations will be very very common.
>
> One I can remember was:
>
>
On Sat, 2007-09-29 at 01:13 -0700, Andrew Morton wrote:
> On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> >
> > On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
> >
> > > > start 2 processes that each mmap a separate 64M file, and which does
> > > >
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
> Really? That means we can no longer even allocate stacks for forking.
I think I'm running with 4k stacks...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
>
> > > start 2 processes that each mmap a separate 64M file, and which does
> > > sequential writes on them. start a 3th process that does the same with
On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
start 2 processes that each mmap a separate 64M file, and which does
sequential writes on them. start a 3th process that does the same with
64M
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
Really? That means we can no longer even allocate stacks for forking.
I think I'm running with 4k stacks...
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Sat, 2007-09-29 at 01:13 -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
start 2 processes that each mmap a separate 64M file, and which does
sequential writes
On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
Ah, right, that was the detail... all this lumpy reclaim is useless for
atomic allocations. And with SLUB using higher order pages, atomic !0
order allocations will be very very common.
One I can remember was:
On Sat, 29 Sep 2007 10:47:12 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sat, 2007-09-29 at 01:13 -0700, Andrew Morton wrote:
On Fri, 28 Sep 2007 20:25:50 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
start 2
On Sat, 29 Sep 2007 10:53:41 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
Ah, right, that was the detail... all this lumpy reclaim is useless for
atomic allocations. And with SLUB using higher order pages, atomic !0
order
On Sat, 2007-09-29 at 02:01 -0700, Andrew Morton wrote:
On Sat, 29 Sep 2007 10:53:41 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sat, 2007-09-29 at 10:47 +0200, Peter Zijlstra wrote:
Ah, right, that was the detail... all this lumpy reclaim is useless for
atomic allocations.
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra [EMAIL PROTECTED] wrote:
oom-killings, or page allocation failures? The latter, one hopes.
Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
(Ubuntu 4.1.2-0ubuntu4)) #27 Tue Sep 18 15:40:35 CEST 2007
...
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra [EMAIL PROTECTED]
wrote:
oom-killings, or page allocation failures? The latter, one hopes.
Linux version 2.6.23-rc4-mm1-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2
(Ubuntu
On Saturday 29 September 2007 04:41, Christoph Lameter wrote:
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
memory got massively fragemented, as anti-frag gets easily defeated.
setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
order blocks to stay available, so we don't
On Sat, 29 Sep 2007 06:19:33 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
On Saturday 29 September 2007 19:27, Andrew Morton wrote:
On Sat, 29 Sep 2007 11:14:02 +0200 Peter Zijlstra [EMAIL PROTECTED]
wrote:
oom-killings, or page allocation failures? The latter, one hopes.
Linux
On Saturday 29 September 2007 03:33, Christoph Lameter wrote:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
> > On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> > > SLAB_VFALLBACK can be specified for selected slab caches. If fallback
> > > is available then the conservative settings
On (28/09/07 11:41), Christoph Lameter didst pronounce:
> On Fri, 28 Sep 2007, Peter Zijlstra wrote:
>
> > memory got massively fragemented, as anti-frag gets easily defeated.
> > setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
> > order blocks to stay available, so we
On (28/09/07 10:33), Christoph Lameter didst pronounce:
> On Fri, 28 Sep 2007, Nick Piggin wrote:
>
> > On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> > > SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
> > > available then the conservative settings for
On (28/09/07 20:25), Peter Zijlstra didst pronounce:
>
> On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
>
> > > start 2 processes that each mmap a separate 64M file, and which does
> > > sequential writes on them. start a 3th process that does the same with
> > > 64M anonymous.
> >
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
> memory got massively fragemented, as anti-frag gets easily defeated.
> setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
> order blocks to stay available, so we don't mix types. however 12M on
> 128M is rather a lot.
Yes, strict
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
> > start 2 processes that each mmap a separate 64M file, and which does
> > sequential writes on them. start a 3th process that does the same with
> > 64M anonymous.
> >
> > wait for a while, and you'll see order=1 failures.
>
>
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
>
> On Fri, 2007-09-28 at 10:33 -0700, Christoph Lameter wrote:
>
> > Again I have not seen any fallbacks to vmalloc in my testing. What we are
> > doing here is mainly to address your theoretical cases that we so far have
> > never seen to be a
On Fri, 2007-09-28 at 10:33 -0700, Christoph Lameter wrote:
> Again I have not seen any fallbacks to vmalloc in my testing. What we are
> doing here is mainly to address your theoretical cases that we so far have
> never seen to be a problem and increase the reliability of allocations of
>
On Fri, 28 Sep 2007, Nick Piggin wrote:
> On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> > SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
> > available then the conservative settings for higher order allocations are
> > overridden. We then request an
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
> SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
> available then the conservative settings for higher order allocations are
> overridden. We then request an order that can accomodate at mininum
> 100 objects.
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The
On Fri, 28 Sep 2007, Nick Piggin wrote:
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order
On Fri, 2007-09-28 at 10:33 -0700, Christoph Lameter wrote:
Again I have not seen any fallbacks to vmalloc in my testing. What we are
doing here is mainly to address your theoretical cases that we so far have
never seen to be a problem and increase the reliability of allocations of
page
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
On Fri, 2007-09-28 at 10:33 -0700, Christoph Lameter wrote:
Again I have not seen any fallbacks to vmalloc in my testing. What we are
doing here is mainly to address your theoretical cases that we so far have
never seen to be a problem and
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
start 2 processes that each mmap a separate 64M file, and which does
sequential writes on them. start a 3th process that does the same with
64M anonymous.
wait for a while, and you'll see order=1 failures.
Really? That
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
memory got massively fragemented, as anti-frag gets easily defeated.
setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
order blocks to stay available, so we don't mix types. however 12M on
128M is rather a lot.
Yes, strict
On (28/09/07 20:25), Peter Zijlstra didst pronounce:
On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
start 2 processes that each mmap a separate 64M file, and which does
sequential writes on them. start a 3th process that does the same with
64M anonymous.
wait for
On (28/09/07 10:33), Christoph Lameter didst pronounce:
On Fri, 28 Sep 2007, Nick Piggin wrote:
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher
On (28/09/07 11:41), Christoph Lameter didst pronounce:
On Fri, 28 Sep 2007, Peter Zijlstra wrote:
memory got massively fragemented, as anti-frag gets easily defeated.
setting min_free_kbytes to 12M does seem to solve it - it forces 2 max
order blocks to stay available, so we don't mix
On Saturday 29 September 2007 03:33, Christoph Lameter wrote:
On Fri, 28 Sep 2007, Nick Piggin wrote:
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
SLAB_VFALLBACK can be specified for selected slab caches. If fallback
is available then the conservative settings for higher
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The size of an individual slab allocation is allowed to reach
up to
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The size of an individual slab allocation is allowed to reach
up to
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The size of an individual slab allocation is allowed to reach
up to
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The size of an individual slab allocation is allowed to reach
up to
74 matches
Mail list logo