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 st
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 allocati
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 "unsubsc
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 c
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 s
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 th
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.
>
> T
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 w
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
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 Se
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 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 do
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
> > > atomi
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
> > or
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:
>
> add_to_page_
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
> > > > s
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 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 fo
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
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 h
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 or
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.
>
> Reall
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 probl
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, 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 ord
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.
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 256
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 256
37 matches
Mail list logo