Christoph Lameter wrote:
On Wed, 22 Aug 2007, Peter Zijlstra wrote:
That is an extreme case that AFAIK we currently ignore and could be
avoided with some effort.
Its not extreme, not even rare, and its handled now. Its what
PF_MEMALLOC is for.
No its not. If you have all pages allocated as a
On Thu, 23 Aug 2007, Andrea Arcangeli wrote:
> On Tue, Aug 21, 2007 at 03:32:25PM -0700, Christoph Lameter wrote:
> > 1. Like in the earlier patchset allow reentry to reclaim under
> >PF_MEMALLOC if we are out of all memory.
>
> Can you simply tweak on the may_writepage flag only to achieve
On Thu, 2007-08-23 at 14:08 +0200, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2007 at 12:09:03AM +0200, Peter Zijlstra wrote:
> > Strictly speaking:
> >
> > if:
> >
> > page = alloc_page(gfp);
> >
> > fails but:
> >
> > obj = kmem_cache_alloc(s, gfp);
> >
> > succeeds then its a bug.
>
> Why
On Wed, Aug 22, 2007 at 10:03:45PM +0200, Peter Zijlstra wrote:
> Its not extreme, not even rare, and its handled now. Its what
> PF_MEMALLOC is for.
Agreed. This is the whole point, either you limit the max amount of
anon memory, slab, alloc_pages a driver can do or you reserve a
pool. Guess what
On Wed, Aug 22, 2007 at 12:09:03AM +0200, Peter Zijlstra wrote:
> Strictly speaking:
>
> if:
>
> page = alloc_page(gfp);
>
> fails but:
>
> obj = kmem_cache_alloc(s, gfp);
>
> succeeds then its a bug.
Why? this is like saying that if alloc_pages(order=1) fails but
alloc_pages(order=0) succe
On Tue, Aug 21, 2007 at 03:32:25PM -0700, Christoph Lameter wrote:
> 1. Like in the earlier patchset allow reentry to reclaim under
>PF_MEMALLOC if we are out of all memory.
Can you simply tweak on the may_writepage flag only to achieve the
second pass? We're talking here about a totally non-
On Wed, 2007-08-22 at 13:16 -0700, Christoph Lameter wrote:
> On Wed, 22 Aug 2007, Peter Zijlstra wrote:
> > > > As shown, there are cases where there just isn't any memory to reclaim.
^^^
> > > > Please accept this.
> >
On Wed, 22 Aug 2007, Peter Zijlstra wrote:
> > That is an extreme case that AFAIK we currently ignore and could be
> > avoided with some effort.
>
> Its not extreme, not even rare, and its handled now. Its what
> PF_MEMALLOC is for.
No its not. If you have all pages allocated as anonymous pages
On Wed, 2007-08-22 at 12:04 -0700, Christoph Lameter wrote:
> On Wed, 22 Aug 2007, Peter Zijlstra wrote:
>
> > Its unavoidable, at some point it just happens. Also using reclaim
> > doesn't seem like the ideal way to get out of live-locks since reclaim
> > itself can live-lock on these large boxen
On Wed, 22 Aug 2007, Ingo Molnar wrote:
> Could you outline the "big picture" as you see it? To me your argument
> that reclaim can always be done instantly and that the cases where it
> cannot be done are pathological and need to be avoided is fundamentally
> dangerous and quite a bit short-si
On Wed, 22 Aug 2007, Peter Zijlstra wrote:
> Its unavoidable, at some point it just happens. Also using reclaim
> doesn't seem like the ideal way to get out of live-locks since reclaim
> itself can live-lock on these large boxen.
If reclaim can live lock then it needs to be fixed.
> As shown, th
* Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > I want slab to fail when a similar page alloc would fail, no magic.
>
> Yes I know. I do not want allocations to fail but that reclaim occurs
> in order to avoid failing any allocation. We need provisions that make
> sure that we never get int
On Tue, 2007-08-21 at 15:43 -0700, Christoph Lameter wrote:
> On Wed, 22 Aug 2007, Peter Zijlstra wrote:
>
> > Also, all I want is for slab to honour gfp flags like page allocation
> > does, nothing more, nothing less.
> >
> > (well, actually slightly less, since I'm only really interrested in th
On Wed, 22 Aug 2007, Peter Zijlstra wrote:
> Also, all I want is for slab to honour gfp flags like page allocation
> does, nothing more, nothing less.
>
> (well, actually slightly less, since I'm only really interrested in the
> ALLOC_MIN|ALLOC_HIGH|ALLOC_HARDER -> ALLOC_NO_WATERMARKS transition
On Tue, 21 Aug 2007, Rik van Riel wrote:
> Christoph Lameter wrote:
>
> > I want general improvements to reclaim to address the issues that you see
> > and other issues related to reclaim instead of the strange code that makes
> > PF_MEMALLOC allocs compete for allocations from a single slab and
On Tue, 2007-08-21 at 14:29 -0700, Christoph Lameter wrote:
> On Tue, 21 Aug 2007, Peter Zijlstra wrote:
>
> > It quickly ends up with all of memory in the laundry list and then
> > recursing into __alloc_pages which will fail to make progress and OOMs.
>
> H... Okay that needs to be addresse
Christoph Lameter wrote:
I want general improvements to reclaim to address the issues that you see
and other issues related to reclaim instead of the strange code that makes
PF_MEMALLOC allocs compete for allocations from a single slab and putting
logic into the kernel to decide which allocs t
On Tue, 21 Aug 2007, Rik van Riel wrote:
> > What is preventing that from occurring right now? If the dirty pags are
> > aligned in the right way you can have the exact same situation.
>
> For one, dirty page writeout is done even when free memory
> is low. The kernel will dig into the PF_MEMALL
On Tue, 21 Aug 2007, Peter Zijlstra wrote:
> It quickly ends up with all of memory in the laundry list and then
> recursing into __alloc_pages which will fail to make progress and OOMs.
H... Okay that needs to be addressed. Reserves need to be used and we
only should enter reclaim if that ru
On Tue, 2007-08-21 at 13:48 -0700, Christoph Lameter wrote:
> On Tue, 21 Aug 2007, Peter Zijlstra wrote:
>
> > This almost insta-OOMs with anonymous workloads.
>
> What does the workload do? So writeout needs to begin earlier. There are
> likely issues with throttling.
The workload is a single
Christoph Lameter wrote:
On Tue, 21 Aug 2007, Rik van Riel wrote:
Christoph Lameter wrote:
1. First reclaiming non dirty pages. Dirty pages are deferred until reclaim
has reestablished the high marks. Then all the dirty pages (the laundry)
is written out.
That sounds like a horrendousl
On Tue, 21 Aug 2007, Dave McCracken wrote:
> On Monday 20 August 2007, Christoph Lameter wrote:
> > 1. First reclaiming non dirty pages. Dirty pages are deferred until reclaim
> > has reestablished the high marks. Then all the dirty pages (the laundry)
> > is written out.
>
> I don't buy it
On Tue, 21 Aug 2007, Rik van Riel wrote:
> Christoph Lameter wrote:
>
> > 1. First reclaiming non dirty pages. Dirty pages are deferred until reclaim
> >has reestablished the high marks. Then all the dirty pages (the laundry)
> >is written out.
>
> That sounds like a horrendously bad ide
On Tue, 21 Aug 2007, Peter Zijlstra wrote:
> This almost insta-OOMs with anonymous workloads.
What does the workload do? So writeout needs to begin earlier. There are
likely issues with throttling.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
On Monday 20 August 2007, Christoph Lameter wrote:
> 1. First reclaiming non dirty pages. Dirty pages are deferred until reclaim
> has reestablished the high marks. Then all the dirty pages (the laundry)
> is written out.
I don't buy it. What happens when there aren't enough clean pages in
Christoph Lameter wrote:
1. First reclaiming non dirty pages. Dirty pages are deferred until reclaim
has reestablished the high marks. Then all the dirty pages (the laundry)
is written out.
That sounds like a horrendously bad idea. While one process
is busy freeing all the non dirty pag
On Mon, 2007-08-20 at 14:50 -0700, Christoph Lameter wrote:
> One of the problems with reclaim writeout is that it occurs when memory in a
> zone is low. A particular bad problem can occur if memory in a zone is
> already low and now the first page that we encounter during reclaim is dirty.
> So th
One of the problems with reclaim writeout is that it occurs when memory in a
zone is low. A particular bad problem can occur if memory in a zone is
already low and now the first page that we encounter during reclaim is dirty.
So the writeout function is called without the filesystem or device havin
28 matches
Mail list logo
