Re: compaction: trying to understand the code

[Wu Fengguang <fengguang.wu@intel.com>]

> From: Minchan Kim <minchan.kim@gmail.com>
> 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. Are the pages isolated by
the compaction process itself?

Thanks,
Fengguang

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>