Re: Problem in Page Cache Replacement

From: Rik van Riel <riel@redhat.com>
To: Fengguang Wu <fengguang.wu@intel.com>
Cc: "Metin Döşlü" <metindoslu@gmail.com>,
	"Jaegeuk Hanse" <jaegeuk.hanse@gmail.com>,
	"Jan Kara" <jack@suse.cz>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"Johannes Weiner" <jweiner@redhat.com>
Subject: Re: Problem in Page Cache Replacement
Date: Sun, 25 Nov 2012 15:08:49 -0500	[thread overview]
Message-ID: <50B27AD1.6010703@redhat.com> (raw)
In-Reply-To: <20121122155318.GA12636@localhost>

On 11/22/2012 10:53 AM, Fengguang Wu wrote:

> Ah it's more likely caused by this logic:
>
>          if (is_active_lru(lru)) {
>                  if (inactive_list_is_low(mz, file))
>                          shrink_active_list(nr_to_scan, mz, sc, priority, file);
>
> The active file list won't be scanned at all if it's smaller than the
> active list. In this case, it's inactive=33586MB > active=25719MB. So
> the data-1 pages in the active list will never be scanned and reclaimed.

That's it, indeed.

The reason we have that code is that otherwise one large streaming
IO could easily end up evicting the entire page cache working set.

Usually it works well, because the new page cache working set tends
to get touched twice while on the inactive list, and the old working
set gets demoted from the active list.

Only in a few very specific cases, where the inter-reference distance
of the new working set is larger than the size of the inactive list,
does it fail.

Something like Johannes's patches should solve the problem.

-- 
All rights reversed