From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 33D196B01AE for ; Tue, 23 Mar 2010 13:32:48 -0400 (EDT) Date: Tue, 23 Mar 2010 12:31:35 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 05/11] Export unusable free space index via /proc/unusable_index In-Reply-To: <1269347146-7461-6-git-send-email-mel@csn.ul.ie> Message-ID: References: <1269347146-7461-1-git-send-email-mel@csn.ul.ie> <1269347146-7461-6-git-send-email-mel@csn.ul.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Mel Gorman Cc: Andrew Morton , Andrea Arcangeli , Adam Litke , Avi Kivity , David Rientjes , Minchan Kim , KAMEZAWA Hiroyuki , KOSAKI Motohiro , Rik van Riel , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Tue, 23 Mar 2010, Mel Gorman wrote: > +/* > + * Return an index indicating how much of the available free memory is > + * unusable for an allocation of the requested size. > + */ > +static int unusable_free_index(unsigned int order, > + struct contig_page_info *info) > +{ > + /* No free memory is interpreted as all free memory is unusable */ > + if (info->free_pages == 0) > + return 1000; Is that assumption correct? If you have no free memory then you do not know about the fragmentation status that would result if you would run reclaim and free some memory. Going into a compaction mode would not be useful. Should this not return 0 to avoid any compaction run when all memory is allocated? Otherwise Reviewed-by: Christoph Lameter -- 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