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 program mapping 256M of anonymous memory and cycling through it with writes ran on a 128M setup. 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. 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. 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. Currently we keep them free, this has the advantage that the buddy allocator can at least try to coalese them. '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. 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
