On Mon, Aug 23, 2010 at 07:23:16AM +0800, Wu Fengguang wrote: > > From: Minchan Kim <minchan.kim@xxxxxxxxx> > > Date: Mon, 23 Aug 2010 00:20:44 +0900 > > Subject: [PATCH] compaction: handle active and inactive fairly in too_many_isolated > > > > Iram reported compaction's too_many_isolated loops forever. > > (http://www.spinics.net/lists/linux-mm/msg08123.html) > > > > The meminfo of situation happened was inactive anon is zero. > > That's because the system has no memory pressure until then. > > While all anon pages was in active lru, compaction could select > > active lru as well as inactive lru. That's different things > > with vmscan's isolated. So we has been two too_many_isolated. > > > > While compaction can isolated pages in both active and inactive, > > current implementation of too_many_isolated only considers inactive. > > It made Iram's problem. > > > > This patch handles active and inactie with fair. > > That's because we can't expect where from and how many compaction would > > isolated pages. > > > > This patch changes (nr_isolated > nr_inactive) with > > nr_isolated > (nr_active + nr_inactive) / 2. > > The change looks good, thanks. However I'm not sure if it's enough. > > I wonder where the >40MB isolated pages come about. inactive_anon > remains 0 and free remains high over a long time, so it seems there > are no concurrent direct reclaims at all. When the proc trigger is used, it is not necessary for there to be any memory pressure for compaction to be running. It's unlikely in this case that there are many processes direct compacting but the check should still not potentially loop. -- 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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>