From: Baokun Li <libaokun1@huawei.com>
To: Jan Kara <jack@suse.cz>
Cc: <linux-ext4@vger.kernel.org>, <tytso@mit.edu>,
<adilger.kernel@dilger.ca>, <ritesh.list@gmail.com>,
<linux-kernel@vger.kernel.org>, <yi.zhang@huawei.com>,
<yangerkun@huawei.com>, <yukuai3@huawei.com>,
Baokun Li <libaokun1@huawei.com>
Subject: Re: [PATCH v3 2/8] ext4: add a new helper to check if es must be kept
Date: Thu, 13 Apr 2023 10:00:56 +0800 [thread overview]
Message-ID: <22b3bfef-7a47-036d-125b-180040a0c743@huawei.com> (raw)
In-Reply-To: <20230412185300.rpfwdlxeiptqaxes@quack3>
On 2023/4/13 2:53, Jan Kara wrote:
> On Wed 12-04-23 20:41:20, Baokun Li wrote:
>> A helper function is added to help determine if the current extent can
>> be dropped, although only ext4_es_is_delayed() extents cannot be dropped
>> currently.
>>
>> Suggested-by: Jan Kara <jack@suse.cz>
>> Signed-off-by: Baokun Li <libaokun1@huawei.com>
> Looks good. Just some small suggestions below...
Thank you very much for your review!
>
>> diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c
>> index 7bc221038c6c..f9dab2510bdc 100644
>> --- a/fs/ext4/extents_status.c
>> +++ b/fs/ext4/extents_status.c
>> @@ -448,6 +448,20 @@ static void ext4_es_list_del(struct inode *inode)
>> spin_unlock(&sbi->s_es_lock);
>> }
>>
>> +/*
>> + * Returns 1 indicates that we cannot fail to allocate memory for this
>> + * extent_status and cannot reclaim, clear, or free the extent until
>> + * its status changes.
>> + */
>> +static inline int ext4_es_must_keep(struct extent_status *es)
> Maybe we can return bool? Also I'd rephrase the comment as:
Totally agree! I tried to move it to fs/ext4/extents_status.h before, so I
changed the function type to int, but later I realized that it was not
necessary
to move it to the header file, but the function type was not changed back.
>
> /*
> * Returns true if we cannot fail to allocate memory for this extent_status
> * entry and cannot reclaim it until its status changes.
> */
OK, looks good, thanks!
>> +{
>> + /* filemap, bigalloc, and seek_data/hole need to use it. */
>> + if (ext4_es_is_delayed(es))
>> + return 1;
>> +
>> + return 0;
>> +}
>> +
>> static struct extent_status *
>> ext4_es_alloc_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len,
>> ext4_fsblk_t pblk)
>> @@ -460,10 +474,8 @@ ext4_es_alloc_extent(struct inode *inode, ext4_lblk_t lblk, ext4_lblk_t len,
>> es->es_len = len;
>> es->es_pblk = pblk;
>>
>> - /*
>> - * We don't count delayed extent because we never try to reclaim them
>> - */
>> - if (!ext4_es_is_delayed(es)) {
>> + /* We never try to reclaim a must kept extent, so we don't count it. */
>> + if (!ext4_es_must_keep(es)) {
>> if (!EXT4_I(inode)->i_es_shk_nr++)
>> ext4_es_list_add(inode);
>> percpu_counter_inc(&EXT4_SB(inode->i_sb)->
>> @@ -481,8 +493,8 @@ static void ext4_es_free_extent(struct inode *inode, struct extent_status *es)
>> EXT4_I(inode)->i_es_all_nr--;
>> percpu_counter_dec(&EXT4_SB(inode->i_sb)->s_es_stats.es_stats_all_cnt);
>>
>> - /* Decrease the shrink counter when this es is not delayed */
>> - if (!ext4_es_is_delayed(es)) {
>> + /* Decrease the shrink counter when this es is not a must be kept */
> Let's rephrase the comment as:
> /* Decrease the shrink counter when we can reclaim the extent */
Okay, this is very nice!
>
>> + if (!ext4_es_must_keep(es)) {
>> BUG_ON(EXT4_I(inode)->i_es_shk_nr == 0);
>> if (!--EXT4_I(inode)->i_es_shk_nr)
>> ext4_es_list_del(inode);
>> @@ -853,7 +865,7 @@ int ext4_es_insert_extent(struct inode *inode, ext4_lblk_t lblk,
>> if (err == -ENOMEM && __es_shrink(EXT4_SB(inode->i_sb),
>> 128, EXT4_I(inode)))
>> goto retry;
>> - if (err == -ENOMEM && !ext4_es_is_delayed(&newes))
>> + if (err == -ENOMEM && !ext4_es_must_keep(&newes))
>> err = 0;
>>
>> if (sbi->s_cluster_ratio > 1 && test_opt(inode->i_sb, DELALLOC) &&
>> @@ -1706,11 +1718,8 @@ static int es_do_reclaim_extents(struct ext4_inode_info *ei, ext4_lblk_t end,
>>
>> (*nr_to_scan)--;
>> node = rb_next(&es->rb_node);
>> - /*
>> - * We can't reclaim delayed extent from status tree because
>> - * fiemap, bigallic, and seek_data/hole need to use it.
>> - */
>> - if (ext4_es_is_delayed(es))
>> + /* We can't reclaim a must be kept extent from status tree. */
> I guess we can just drop this comment. The function name explains enough...
Totally agree!
>
>> + if (ext4_es_must_keep(es))
>> goto next;
>> if (ext4_es_is_referenced(es)) {
>> ext4_es_clear_referenced(es);
> Honza
Can you please help review the remaining patches for any problems?
If you have any suggestions, I'll fix them together and post another
version of v4.
Thanks again for your review!
--
With Best Regards,
Baokun Li
.
next prev parent reply other threads:[~2023-04-13 2:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 12:41 [PATCH v3 0/8] ext4: fix WARNING in ext4_da_update_reserve_space Baokun Li
2023-04-12 12:41 ` [PATCH v3 1/8] ext4: only update i_reserved_data_blocks on successful block allocation Baokun Li
2023-04-12 18:45 ` Jan Kara
2023-04-12 12:41 ` [PATCH v3 2/8] ext4: add a new helper to check if es must be kept Baokun Li
2023-04-12 18:53 ` Jan Kara
2023-04-13 2:00 ` Baokun Li [this message]
2023-04-13 10:34 ` Jan Kara
2023-04-13 12:26 ` Baokun Li
2023-04-12 12:41 ` [PATCH v3 3/8] ext4: use __GFP_NOFAIL if allocating extents_status cannot fail Baokun Li
2023-04-13 10:30 ` Jan Kara
2023-04-24 3:45 ` Baokun Li
2023-04-12 12:41 ` [PATCH v3 4/8] ext4: make __es_remove_extent return void Baokun Li
2023-04-12 12:41 ` [PATCH v3 5/8] ext4: make ext4_es_remove_extent " Baokun Li
2023-04-12 12:41 ` [PATCH v3 6/8] ext4: make ext4_es_insert_delayed_block " Baokun Li
2023-04-12 14:19 ` kernel test robot
2023-04-13 2:36 ` Baokun Li
2023-04-12 17:24 ` kernel test robot
2023-04-12 12:41 ` [PATCH v3 7/8] ext4: make ext4_es_insert_extent " Baokun Li
2023-04-12 12:41 ` [PATCH v3 8/8] ext4: make ext4_zeroout_es " Baokun Li
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=22b3bfef-7a47-036d-125b-180040a0c743@huawei.com \
--to=libaokun1@huawei.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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