All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: linux-ext4@vger.kernel.org, Zheng Liu <wenqing.lz@taobao.com>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	Jan Kara <jack@suse.cz>
Subject: Re: [RFC PATCH v2 0/4] ext4: extents status tree shrinker improvement
Date: Mon, 21 Apr 2014 10:54:16 -0400	[thread overview]
Message-ID: <20140421145416.GA18564@thunk.org> (raw)
In-Reply-To: <20140421144646.GB19966@gmail.com>

On Mon, Apr 21, 2014 at 10:46:46PM +0800, Zheng Liu wrote:
> I am not sure that I fully understand your meaning.  AFAIU, we have a
> list which uses RR scheme to shrink extent caches.  In this list it
> tracks written/unwrittten/hole extent caches.  When the shrinker tries
> to reclaim some objects, it will scan this list and reclaim all extent
> caches whose ref count are less than a number.  Meanwhile the ref count
> of rest caches will be decreased and moved into active list.  In active
> list it tracks all delayed extent caches, precached extent caches and
> other caches that have been promoted.  The shrinker uses LRU algorithm
> to reclaim objects from active list.  Please let me know if I miss
> something.

Yes, that's right.  I misunderstood your analogy to how it's like the
MM.  It is much like the page aging algorithm in that the work done by
the MMU is very minimal, and most of the work is done in the scanning
algorithm.  It might be that a pure "clock algorithm", would work
better than something which is closer to a GC like scheme with a
"tenured" and "nursery" space".  It certainly would be simpler to
implement.

So it's certainly something that's worth considering.

Cheers,

						- Ted

  reply	other threads:[~2014-04-21 14:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 11:30 [RFC PATCH v2 0/4] ext4: extents status tree shrinker improvement Zheng Liu
2014-04-16 11:30 ` [RFC PATCH v2 1/4] ext4: improve extents status tree trace point Zheng Liu
2014-04-16 11:30 ` [RFC PATCH v2 2/4] ext4: track extent status tree shrinker delay statictics Zheng Liu
2014-04-16 11:30 ` [RFC PATCH v2 3/4] ext4: improve extents status tree shrinker lru algorithm Zheng Liu
2014-04-16 11:30 ` [RFC PATCH v2 4/4] ext4: use a round-robin algorithm to shrink extent cache Zheng Liu
2014-04-16 15:19 ` [RFC PATCH v2 0/4] ext4: extents status tree shrinker improvement Theodore Ts'o
2014-04-16 15:42   ` Theodore Ts'o
2014-04-17 15:35     ` Theodore Ts'o
2014-04-21 13:50       ` Zheng Liu
2014-04-21 14:05         ` Theodore Ts'o
2014-04-21 14:46           ` Zheng Liu
2014-04-21 14:54             ` Theodore Ts'o [this message]
2014-04-21 23:10       ` Dave Chinner
2014-04-23  5:35         ` Zheng Liu
2014-04-24  1:46           ` Dave Chinner

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=20140421145416.GA18564@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=wenqing.lz@taobao.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.