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@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>