linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: "nai.xia" <nai.xia@gmail.com>
Cc: linux-mm@kvack.org, Rik van Riel <riel@redhat.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	Hugh Dickins <hughd@google.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/5] refault distance-based file cache sizing
Date: Wed, 16 May 2012 08:51:32 +0200	[thread overview]
Message-ID: <20120516065132.GC1769@cmpxchg.org> (raw)
In-Reply-To: <4FB33A4E.1010208@gmail.com>

Hi Nai,

On Wed, May 16, 2012 at 01:25:34PM +0800, nai.xia wrote:
> Hi Johannes,
> 
> Just out of curiosity(since I didn't study deep into the
> reclaiming algorithms), I can recall from here that around 2005,
> there was an(or some?) implementation of the "Clock-pro" algorithm
> which also have the idea of "reuse distance", but it seems that algo
> did not work well enough to get merged? Does this patch series finally
> solve the problem(s) with "Clock-pro" or totally doesn't have to worry
> about the similar problems?

As far as I understood, clock-pro set out to solve more problems than
my patch set and it failed to satisfy everybody.

The main error case was that it could not partially cache data of a
set that was bigger than memory.  Instead, looping over the file
repeatedly always has to read every single page because the most
recent page allocations would push out the pages needed in the nearest
future.  I never promised to solve this problem in the first place.
But giving more memory to the big looping load is not useful in our
current situation, and at least my code protects smaller sets of
active cache from these loops.  So it's not optimal, but it sucks only
half as much :)

There may have been improvements from clock-pro, but it's hard to get
code merged that does not behave as expected in theory with nobody
understanding what's going on.

My code is fairly simple, works for the tests I've done and the
behaviour observed so far is understood (at least by me).

  reply	other threads:[~2012-05-16  6:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-01  8:41 [patch 0/5] refault distance-based file cache sizing Johannes Weiner
2012-05-01  8:41 ` [patch 1/5] mm: readahead: move radix tree hole searching here Johannes Weiner
2012-05-01 21:06   ` Rik van Riel
2012-05-01  8:41 ` [patch 2/5] mm + fs: prepare for non-page entries in page cache Johannes Weiner
2012-05-01 19:02   ` Andrew Morton
2012-05-01 20:15     ` Johannes Weiner
2012-05-01 20:24       ` Andrew Morton
2012-05-01 21:14         ` Rik van Riel
2012-05-01 21:29         ` Johannes Weiner
2012-05-01  8:41 ` [patch 3/5] mm + fs: store shadow pages " Johannes Weiner
2012-05-01  8:41 ` [patch 4/5] mm + fs: provide refault distance to page cache instantiations Johannes Weiner
2012-05-01  9:30   ` Peter Zijlstra
2012-05-01  9:55     ` Johannes Weiner
2012-05-01  9:58       ` Peter Zijlstra
2012-05-01  8:41 ` [patch 5/5] mm: refault distance-based file cache sizing Johannes Weiner
2012-05-01 14:13   ` Minchan Kim
2012-05-01 15:38     ` Johannes Weiner
2012-05-02  5:21       ` Minchan Kim
2012-05-02  1:57   ` Andrea Arcangeli
2012-05-02  6:23     ` Johannes Weiner
2012-05-02 15:11       ` Andrea Arcangeli
2012-05-01 19:08 ` [patch 0/5] " Andrew Morton
2012-05-01 21:19   ` Rik van Riel
2012-05-01 21:26     ` Andrew Morton
2012-05-02  1:10       ` Andrea Arcangeli
2012-05-03 13:15       ` Johannes Weiner
2012-05-16  5:25 ` nai.xia
2012-05-16  6:51   ` Johannes Weiner [this message]
2012-05-16 12:56     ` nai.xia
2012-05-17 21:08       ` Johannes Weiner
2012-05-18  3:44         ` Nai Xia
2012-05-18 15:07           ` Rik van Riel
2012-05-18 15:30             ` Nai Xia
2012-05-17 13:11   ` Rik van Riel
2012-05-18  5:03     ` Nai Xia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120516065132.GC1769@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=minchan.kim@gmail.com \
    --cc=nai.xia@gmail.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).