[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130718011940.GA8785@gmail.com>
Date: Thu, 18 Jul 2013 09:19:41 +0800
From: Zheng Liu <gnehzuil.liu@...il.com>
To: Theodore Ts'o <tytso@....edu>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 5/5] ext4: add new ioctl EXT4_IOC_PRECACHE_EXTENTS
On Tue, Jul 16, 2013 at 11:18:03AM -0400, Theodore Ts'o wrote:
> Add a new ioctl which forces the all of the extents in an inode to be
> cached in the extent_status tree. This is critically important when
> using AIO to a preallocated file, since if we need to read in blocks
> from the extent tree, the io_submit(2) system call becomes
> synchronous, and the AIO is no longer "A", which is bad.
>
> In addition, for most files which have an external leaf tree block,
> the cost of caching the information in the extent status tree will be
> less than caching the entire 4k block in the buffer cache. So it is
> generally a win to keep the extent information cached.
> ---
[...]
> @@ -1069,10 +1072,16 @@ static int __es_try_to_reclaim_extents(struct ext4_inode_info *ei,
> struct rb_node *node;
> struct extent_status *es;
> int nr_shrunk = 0;
> + static DEFINE_RATELIMIT_STATE(_rs, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
>
> if (ei->i_es_lru_nr == 0)
> return 0;
>
> + if (ext4_test_inode_state(inode, EXT4_STATE_EXT_PRECACHED) &&
> + __ratelimit(&_rs))
> + ext4_warning(inode->i_sb, "forced shrink of precached extents");
If I understand correctly, we don't want to reclaim from an inode with
EXT4_STATE_EXT_PRECACHED flag when __ratelimit() returns 0, right? So
I propose the following code:
if (ext4_test_inode_state(inode, EXT4_STATE_EXT_PRECACHED) {
if (!__ratelimit(&_rs))
return 0;
ext4_warning(inode->i_sb, "forced shrink of precached extents");
}
- Zheng
> +
> node = rb_first(&tree->root);
> while (node != NULL) {
> es = rb_entry(node, struct extent_status, rb_node);
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists