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: Thu, 13 Jun 2013 21:27:15 +0800 [thread overview]
Message-ID: <20130613132715.GA12622@gmail.com> (raw)
In-Reply-To: <20130612204854.GA12456@thunk.org>
Hi Ted,
On Wed, Jun 12, 2013 at 04:48:54PM -0400, Theodore Ts'o wrote:
> On Wed, Jun 12, 2013 at 08:09:14AM -0700, Dave Hansen wrote:
> > You could make per-cpu LRUs, and batch movement on and off the global
> > LRU once the local ones get to be a certain size. Or, you could keep
> > them cpu-local *until* the shrinker is called, when the shrinker could
> > go drain all the percpu ones.
> >
> > Or, you could tag each extent in memory with its last-used time. You
> > write an algorithm to go and walk the tree and attempt to _generally_
> > free the oldest objects out of a limited window.
>
> Another approach might be to tag each inode with the last time an
> ext4_map_blocks() was called on the inode, and keep an unsorted list
> of inodes which has one or more entries in the extent cache.
>
> When we decide to discard entries from the extent cache, we should
> drop all of the entries for the inode --- and then when we read in
> part of the extent tree leaf block, we should create entries in the
> extent cache for all of the extents found in the extent leaf block.
Thanks for your suggestion. But, sorry, I couldn't get your point here.
As you suggested above, we can tag each inode with the last access time
when ext4_map_blocks() is called. Then we will get an unsorted list of
inodes with some extent entries. When we tries to reclaim some entries
from extent cache, we can call list_sort() to get an sorted list of
inodes and try to reclaim some entries according to the last access
time. My question is why do we need to drop all of the entries from all
inodes.
Af far as I understand, we can do the following improvement. We tag the
last access time for each inode. So that would avoid to move the inode
in lru list frequently. When we try to reclaim some entries, we call
list_sort() to get a sorted lru list, and drop some entries from lru
list. Please correct me if I misunderstood.
For creating all extent leaf blocks, that is another improvement. I
will try to add it after I solve current problem that Dave reported.
Thanks,
- Zheng
next prev parent reply other threads:[~2013-06-13 13:27 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 [this message]
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
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=20130613132715.GA12622@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).