On Thursday 25 October 2007 12:43, Christoph Lameter wrote:
> On Thu, 25 Oct 2007, Nick Piggin wrote:
> > > Ummm... all unreclaimable is set! Are you mlocking the pages in memory?
> > > Or what causes this? All pages under writeback? What is the dirty ratio
> > > set to?
> >
> > Why is SLUB
On Thu, 25 Oct 2007, Nick Piggin wrote:
> > Ummm... all unreclaimable is set! Are you mlocking the pages in memory? Or
> > what causes this? All pages under writeback? What is the dirty ratio set
> > to?
>
> Why is SLUB behaving differently, though.
Nore sure. Are we really sure that this does
On Thursday 25 October 2007 12:15, Christoph Lameter wrote:
> On Wed, 24 Oct 2007, Alexey Dobriyan wrote:
> > [12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB
> > inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable?
> > yes [12728.701567] lowmem_reserve[]:
On Wed, 24 Oct 2007, Alexey Dobriyan wrote:
> [12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB
> inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable?
> yes [12728.701567] lowmem_reserve[]: 0 2003 2003 2003 [12728.701654]
Ummm... all unreclaimable is
On Wed, Oct 24, 2007 at 09:09:38AM +0100, Mel Gorman wrote:
> On (23/10/07 12:57), Christoph Lameter didst pronounce:
> > On Tue, 23 Oct 2007, Pekka Enberg wrote:
> >
> > > > > cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
> > >
> > > Christoph Lameter wrote:
> > > > Regular
On Tue, 23 Oct 2007, Pekka Enberg wrote:
> Yeah, but we're _not failing_ when debugging is enabled. Thus, it's
> likely, that the _failing_ (non-debug) case has potential for more
> order 0 allocs, no? I am just guessing here but maybe it's
> slab_order() behaving differently from
On (23/10/07 12:57), Christoph Lameter didst pronounce:
> On Tue, 23 Oct 2007, Pekka Enberg wrote:
>
> > > > cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
> >
> > Christoph Lameter wrote:
> > > Regular Order 0 alloc but why is there no memory available ,
> > > reclaimed?
On Wed, 24 Oct 2007, Alexey Dobriyan wrote:
[12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB
inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable?
yes [12728.701567] lowmem_reserve[]: 0 2003 2003 2003 [12728.701654]
Ummm... all unreclaimable is set!
On Thursday 25 October 2007 12:15, Christoph Lameter wrote:
On Wed, 24 Oct 2007, Alexey Dobriyan wrote:
[12728.701398] DMA free:8032kB min:32kB low:40kB high:48kB active:2716kB
inactive:2208kB present:12744kB pages_scanned:9299 all_unreclaimable?
yes [12728.701567] lowmem_reserve[]: 0 2003
On Thu, 25 Oct 2007, Nick Piggin wrote:
Ummm... all unreclaimable is set! Are you mlocking the pages in memory? Or
what causes this? All pages under writeback? What is the dirty ratio set
to?
Why is SLUB behaving differently, though.
Nore sure. Are we really sure that this does not
On Thursday 25 October 2007 12:43, Christoph Lameter wrote:
On Thu, 25 Oct 2007, Nick Piggin wrote:
Ummm... all unreclaimable is set! Are you mlocking the pages in memory?
Or what causes this? All pages under writeback? What is the dirty ratio
set to?
Why is SLUB behaving
On (23/10/07 12:57), Christoph Lameter didst pronounce:
On Tue, 23 Oct 2007, Pekka Enberg wrote:
cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc but why is there no memory available ,
reclaimed?
I am too
On Tue, 23 Oct 2007, Pekka Enberg wrote:
Yeah, but we're _not failing_ when debugging is enabled. Thus, it's
likely, that the _failing_ (non-debug) case has potential for more
order 0 allocs, no? I am just guessing here but maybe it's
slab_order() behaving differently from
On Wed, Oct 24, 2007 at 09:09:38AM +0100, Mel Gorman wrote:
On (23/10/07 12:57), Christoph Lameter didst pronounce:
On Tue, 23 Oct 2007, Pekka Enberg wrote:
cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc
Hi Christoph,
(I fixed linux-mm cc to kvack.org.)
On 10/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> The number of objects per page is reduced by enabling full debugging. That
> triggers a potential of more order 1 allocations but we are failing at
> order 0 allocs.
Yeah, but we're
On Tue, 23 Oct 2007, Pekka Enberg wrote:
> On 10/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > Not sure what this is. Maybe the slowing SLUB solves the race.
>
> What kind of race are you thinking of? What I initially thought was
> that the problem is that SLUB messes up some other VM
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
> > With SLAB this workload never went to OOM killer.
> > With SLUB and pretty much all debugging enabled, it finishes to the end
> > (albeit slowly).
> > With SLUB and no debugging, OOM killer kicks in.
On 10/23/07, Christoph Lameter <[EMAIL
On Tue, 23 Oct 2007, Pekka Enberg wrote:
> > > cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
>
> Christoph Lameter wrote:
> > Regular Order 0 alloc but why is there no memory available , reclaimed?
>
> I am too wondering where all that memory is going. Logging
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
> cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc but why is there no memory available ,
reclaimed?
I am too wondering where all that memory is going. Logging /proc/meminfo
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
> Nasty OOM killings appear during massive parallel kernel builds with
> SLUB, but not with SLAB. By nasty I mean, cc1 processes are killed --
> object files in .ccache and tree are corrupted which makes me to
> blow up them entirely.
H... Memory
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
Nasty OOM killings appear during massive parallel kernel builds with
SLUB, but not with SLAB. By nasty I mean, cc1 processes are killed --
object files in .ccache and tree are corrupted which makes me to
blow up them entirely.
H... Memory is
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc but why is there no memory available ,
reclaimed?
I am too wondering where all that memory is going. Logging /proc/meminfo
On Tue, 23 Oct 2007, Pekka Enberg wrote:
cc1 invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
Christoph Lameter wrote:
Regular Order 0 alloc but why is there no memory available , reclaimed?
I am too wondering where all that memory is going. Logging /proc/meminfo and
Hi,
On Tue, 23 Oct 2007, Alexey Dobriyan wrote:
With SLAB this workload never went to OOM killer.
With SLUB and pretty much all debugging enabled, it finishes to the end
(albeit slowly).
With SLUB and no debugging, OOM killer kicks in.
On 10/23/07, Christoph Lameter [EMAIL PROTECTED]
On Tue, 23 Oct 2007, Pekka Enberg wrote:
On 10/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
Not sure what this is. Maybe the slowing SLUB solves the race.
What kind of race are you thinking of? What I initially thought was
that the problem is that SLUB messes up some other VM
Hi Christoph,
(I fixed linux-mm cc to kvack.org.)
On 10/23/07, Christoph Lameter [EMAIL PROTECTED] wrote:
The number of objects per page is reduced by enabling full debugging. That
triggers a potential of more order 1 allocations but we are failing at
order 0 allocs.
Yeah, but we're _not
26 matches
Mail list logo
