From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 7 Nov 2006 18:14:31 +0000 (GMT) From: Mel Gorman Subject: Re: Page allocator: Single Zone optimizations In-Reply-To: Message-ID: References: <20061101123451.3fd6cfa4.akpm@osdl.org> <454A2CE5.6080003@shadowen.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Andy Whitcroft , Andrew Morton , Nick Piggin , KAMEZAWA Hiroyuki , Linux Memory Management List , Peter Zijlstra List-ID: On Tue, 7 Nov 2006, Christoph Lameter wrote: > On Tue, 7 Nov 2006, Mel Gorman wrote: > >> Hence, I'm still convinced that slab pages for caches like inode and >> short-lived allocations need to be clustered separetly. > > So the problem seems to be that some slab of "reclaimable" slabs are > not reclaimable at all even with the most aggressive approach? > Right. You may be able to shrink the slab cache considerably, but still not empty it. By clustering the pages together, shrinking all the caches has a chance of freeing up high order pages but there is no guarantee of course. > Then we have a fundamental issue that we are unable to categorize > pages correctly. EasyReclaimable pages may be unreclaimable because they > are mlocked. They are migratable though. In the patchset I am currently working on, I identify pages as Movable, Reclaimable and Unmovable. The redefinitions are a bit more logical (especially for mlock) and move away from the idea of page reclaim being the only way of getting high order allocations to succeed. > Reclaimable (such as slab pages) may turn out to be not > reclaimable because some entries are pinned. > yep. That will hurt hugepage allocations in those blocks but it should help allocations required for network cards with large MTUs for example. > I think we will run into the same issues for EasyReclaim once an > application generates a sufficient amount of mlocked pages that are > placed all over the memory of interest. > Yep, I agree. At that point, migration will be required but the clustering will be in place so that moving all the "movable" pages will result in large contiguous free pages. > Could it be that the only reason that the current approach works is that > we have not tested with an application that behaves this way? > Probably. The applications I currently test are not mlocking. The tests currently run workloads that are known to leave the system in a fragmented state when they complete. In this situation, higher-order allocations fail even when nothing is running and there are no mlocked() pages on the standard allocator. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org