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 behavin
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 n
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
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 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 Or
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 calculate_slab_o
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?
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
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 h
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 PROTEC
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/memin
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 is
13 matches
Mail list logo
