From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 30 Apr 2007 19:33:29 +0100 (IST) From: Mel Gorman Subject: Re: Antifrag patchset comments In-Reply-To: Message-ID: References: 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: Nick Piggin , Linux Memory Management List List-ID: On Mon, 30 Apr 2007, Christoph Lameter wrote: > On Mon, 30 Apr 2007, Mel Gorman wrote: > >>> Indeed that is a good thing.... It would be good if a movable area >>> would be a dynamic split of a zone and not be a separate zone that has to >>> be configured on the kernel command line. >> There are problems with doing that. In particular, the zone can only be sized >> on one direction and can only be sized at the zone boundary because zones do >> not currently overlap and I believe there will be assumptions made about them >> not overlapping within a node. It's worth looking into in the future but I'm >> putting it at the bottom of the TODO list. > > Its is better to have a dynamic limit rather than OOMing. > I'll certainly give the problem a kick. I simply have a strong feeling that dynamically resizing zones will not be very straight-forward and as the zone is manually sized by the administrator, I didn't feel strongly about it being possible for an admin to put his machine in an OOM-able situation. >>>> If the RECLAIMABLE areas could be properly targeted, it would make sense >>>> to >>>> mark these pages RECLAIMABLE instead but that is not the situation today. >>> What is the problem with targeting? >> It's currently not possible to target effectively. > > Could you be more specific? > The situation I wanted to end up with was that a percentage of memory could be reclaimed or moved so that contiguous allocations would succeed. When reclaiming __GFP_MOVABLE, we can use lumpy reclaim to find a suitable area of pages to reclaim. Some of the pages there are buffer pages even though they are not movable in the page migration sense of the word. Given a page allocated for an inode slab cache, we can't reclaim the objects in there in the same way as a buffer page can be cleaned and discared. Hence, to increase the amount of memory that can be reclaimed for contiguous allocations, I group the buffer pages with other movable pages instead of putting them in with __GFP_RECLAIMABLE pages like slab where they are not as useful from a future contiguous allocation perspective. In the event that given a page of slab objects I could be sure of reclaiming all the objects in that page and freeing it, then it would make sense to group buffer pages with those. Does that make sense? >>>> Because they might be ramfs pages which are not movable - >>>> http://lkml.org/lkml/2006/11/24/150 >>> >>> URL does not provide any useful information regarding the issue. >>> >> >> Not all pages allocated via shmem_alloc_page() are movable because they may >> pages for ramfs. > > Not familiar with ramfs. There would have to be work on ramfs to make them > movable? Minimally yes. I haven't looked too closely at the issue yet because to start with, it was enough to know that the pages were not always movable or reclaimable in any way other than deleting files. -- 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