From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx165.postini.com [74.125.245.165]) by kanga.kvack.org (Postfix) with SMTP id 1C34F6B0161 for ; Thu, 13 Sep 2012 13:11:31 -0400 (EDT) Date: Thu, 13 Sep 2012 19:11:27 +0200 From: Andrea Arcangeli Subject: Re: [patch 1/2 v2]compaction: abort compaction loop if lock is contended or run too long Message-ID: <20120913171127.GI3388@redhat.com> References: <20120910011830.GC3715@kernel.org> <20120911163455.bb249a3c.akpm@linux-foundation.org> <20120912004840.GI27078@redhat.com> <20120912142019.0e06bf52.akpm@linux-foundation.org> <20120912234808.GC3404@redhat.com> <20120913004722.GA5085@bbox> <20120913093826.GT11266@suse.de> <20120913160432.GG3388@redhat.com> <20120913163151.GC11266@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120913163151.GC11266@suse.de> Sender: owner-linux-mm@kvack.org List-ID: To: Mel Gorman Cc: Minchan Kim , Andrew Morton , Shaohua Li , linux-mm@kvack.org On Thu, Sep 13, 2012 at 05:31:51PM +0100, Mel Gorman wrote: > On Thu, Sep 13, 2012 at 06:04:32PM +0200, Andrea Arcangeli wrote: > > On Thu, Sep 13, 2012 at 10:38:26AM +0100, Mel Gorman wrote: > > > I agree with Minchan. Andrea's patch ignores the fact that free page > > > isolation might have aborted due to lock contention. It's not necessarily > > > going to be isolating the pages it needs for migration. > > > > Actually I thought of calling putback_lru_pages first, but then I > > thought it was better to just complete the current slice. > > > > Unfortunately that will end up calling compaction_alloc() -> > isolate_freepages and probably end up contending again. > > > Note that putback_lru_pages can take the lru_lock immediately too when > > True, but in that case there is no choice in the matter. We can't just > leak the pages. This is why in that case (if the contention was generated by the lru_lock) we would be better off to go ahead and do migrate_pages. We could track contended_lru_lock and contended_zone_lock separately to know if it's that case or not, but then I doubt it matters that much. > To me, that will just contend more than we have to. We're aborting compaction > and finishing off the current slice will not make any meaningful difference > to whether tha allocation succeeds or not. If you prefer the putback_lru_pages I'm fine, I only wanted to clarify neither of the two solutions is going to do the optimal thing at all times. -- 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