Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks

[Christoph Lameter <clameter@sgi.com>]

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.

Hmmmm... Okay that needs to be addressed. Reserves need to be used and we 
only should enter reclaim if that runs out (like the first patch that I 
did).

> But aside from the numerous issues with the patch set as presented, I'm
> not seeing the seeing the big picture, why are you doing this.

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 to fail. We can reclaim after 
all. Its just a matter of finding the right way to do this. 

> Anonymous pages are a there to stay, and we cannot tell people how to
> use them. So we need some free or freeable pages in order to avoid the
> vm deadlock that arises from all memory dirty.

No one is trying to abolish Anonymous pages. Free memory is readily 
available on demand if one calls reclaim. Your scheme introduces complex 
negotiations over a few scraps of memory when large amounts of memory 
would still be readily available if one would do the right thing and call 
into reclaim.

> 'Optimizing' this by switching to freeable pages has mainly
> disadvantages IMHO, finding them scrambles LRU order and complexifies
> relcaim and all that for a relatively small gain in space for clean
> pagecache pages.

Sounds like you would like to change the way we handle memory in general 
in the VM? Reclaim (and thus finding freeable pages) is basic to Linux 
memory management.

> Please, stop writing patches and write down a solid proposal of how you
> envision the VM working in the various scenarios and why its better than
> the current approach.

Sorry I just got into this a short time ago and I may need a few cycles 
to get this all straight. An approach that uses memory instead of 
ignoring available memory is certainly better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/