linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>,
	Dave Hansen <dave.hansen@intel.com>,
	linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Jan kara <jack@suse.cz>
Subject: Re: ext4 extent status tree LRU locking
Date: Sat, 15 Jun 2013 01:00:28 +0800	[thread overview]
Message-ID: <20130614170028.GA21544@gmail.com> (raw)
In-Reply-To: <20130614140215.GA1017@thunk.org>

On Fri, Jun 14, 2013 at 10:02:15AM -0400, Theodore Ts'o wrote:
> On Fri, Jun 14, 2013 at 10:09:40PM +0800, Zheng Liu wrote:
> > This commit tries to fix this problem.  Now a new member called
> > i_touch_when is added into ext4_inode_info to record the last access
> > time for an inode.  Meanwhile we never need to keep a proper in-order
> > LRU list.  So this can avoid to burns some CPU time.  When we try to
> > reclaim some entries from extent status tree, we use list_sort() to get
> > a proper in-order list.  Then we traverse this list to discard some
> > entries.
> 
> I think this approach is very sound.  I have one reservation, however.
> If there are a large number of inodes on this list, list_sort() could
> burn a lot of CPU time, especially if the shrinker is called a very
> large number of times in a short time period (i.e., when the system is
> thrashing, or when one or more memory containers are under a large
> amount of memory pressure).
> 
> I have a suggestion for how to address this: Keep a timestamp of when
> the list last has been sorted in struct ext4_super_info.  When
> iterating over the list, looking for a candidate inode, if inode's
> i_touch_when is greater than the last time sorted, skip the inode.  If
> there are no inodes left in the list, or more than some threshold
> inodes have been skipped, only then resort the list (and update the
> timestamp in the ext4_super_info structure).
> 
> What do you think?

Thanks for your suggestion.  I fully agree with you.  What I concern is
how to define this threshold.  A fixed value is very simple but too
inflexible.  If this value is too big, this lru list could never be
sorted.  So my proposal is that we set this value accroding to the
number of used inodes.  For example, if the number of used inodes is
10,000, this threshold could be set to 10 (10,000 x 0.1%).  Meanwhile,
we need to provide a sysfs interface to let user set this value.  Does
it make sense?

Thanks,
                                                - Zheng

  reply	other threads:[~2013-06-14 17:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-11 23:22 ext4 extent status tree LRU locking Dave Hansen
2013-06-12  7:17 ` Zheng Liu
2013-06-12 15:09   ` Dave Hansen
2013-06-12 16:03     ` Zheng Liu
2013-06-12 17:52       ` Dave Hansen
2013-06-12 20:48     ` Theodore Ts'o
2013-06-13 13:27       ` Zheng Liu
2013-06-13 13:35         ` Theodore Ts'o
2013-06-14  3:27           ` Zheng Liu
2013-06-14 14:09 ` Zheng Liu
2013-06-14 14:02   ` Theodore Ts'o
2013-06-14 17:00     ` Zheng Liu [this message]
2013-06-14 18:00       ` Theodore Ts'o
2013-06-17 10:10         ` Zheng Liu
2013-06-17 21:12           ` Dave Hansen
2013-06-18  2:25             ` Zheng Liu
2013-06-18  2:51               ` Theodore Ts'o
2013-06-18  3:49                 ` Zheng Liu
2013-06-18  2:47           ` Theodore Ts'o
2013-06-14 15:57   ` Dave Hansen
2013-06-14 17:11     ` Zheng Liu
2013-06-14 16:55       ` Dave Hansen

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=20130614170028.GA21544@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=dave.hansen@intel.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).