Message ID | 20230209194825.511043-4-shikemeng@huaweicloud.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp289488wrn; Thu, 9 Feb 2023 03:59:12 -0800 (PST) X-Google-Smtp-Source: AK7set9stkk5Gsv8ss6NUhqMi1u0U2pMfbrvLbKaRJ3afazoXi9t4aLJghJX9koCP4+v6EANPKon X-Received: by 2002:a05:6a20:12d2:b0:be:b8bd:83ad with SMTP id v18-20020a056a2012d200b000beb8bd83admr13606411pzg.0.1675943952431; Thu, 09 Feb 2023 03:59:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675943952; cv=none; d=google.com; s=arc-20160816; b=0YR72Pi96P3BjLchf0R1HT0CXqqsghC9ZrS7RL7wW8/gKhRMHEx45pgMyZCy7f28jB PlUynUteRAytImXHUXZSgJWRYByu0lFmi4saWQNm6e0tvy07VUkv6JM4SNoS6+kAbCry dt57Kadp/e+jVgrQtEwowFh2DoMfjm8Zob/OhL9/bluHDJjFHBiC6tmp7VpS6RJg0zM3 k3BPONdaZXDKedAI6ffEnaqWqu5y9L5s11djTpVP3IxUmg3zRpRgbZTeu9ZuE9ZsvIVX D7jpmFxSBa3fGAwJ3WTjemQFmqTpi+qND48k3i1X63M23Ipqd2dTw1VVZeGyblUncPCv XRAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=q/obnqL0ND5KZyFMi04eWnGu9vKHcZPL8/rq04Qcu8A=; b=pXV0tMIjyKDKaduM7jfVayuBiOFdlKnw1X/6DLCO8GZJq24b30WdOiZGd0Raea/DY6 bzScHTNw6CoDCto49hXlLN6LTu1QEKfIKQaH4rxTBxDtLnzWQx0YF4XbyAxutu8d6XEw DxJFM0US84a0Xr8La0GstKVgZDk4c+3EOJGdzgDtjLE00CqzbpgoI8oV7AMRpkZawKsk cq5Wurs7+LtYh2f+R76nMHrVSvRQOyNVFDfibCq+LCzjyLHNKXkz3Q8cbqDoMwhsP9MI peaah9PGmwjYXS7xt+97H4g+5ETIt2Mp8Wv/kO1Fw45b/Ae5N2Zy/nDEmioC1vA1YJjm 7eVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w71-20020a63824a000000b004d058989ad7si118672pgd.255.2023.02.09.03.58.59; Thu, 09 Feb 2023 03:59:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229951AbjBIL5H (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 9 Feb 2023 06:57:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229460AbjBIL4L (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Feb 2023 06:56:11 -0500 Received: from dggsgout11.his.huawei.com (dggsgout11.his.huawei.com [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8281F5C481; Thu, 9 Feb 2023 03:46:29 -0800 (PST) Received: from mail02.huawei.com (unknown [172.30.67.169]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4PCFSc4Kx3z4f3jLW; Thu, 9 Feb 2023 19:46:24 +0800 (CST) Received: from huaweicloud.com (unknown [10.175.124.27]) by APP4 (Coremail) with SMTP id gCh0CgAn3rEQ3eRjgb0tDQ--.53508S5; Thu, 09 Feb 2023 19:46:26 +0800 (CST) From: Kemeng Shi <shikemeng@huaweicloud.com> To: tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 03/21] ext4: avoid to use preallocated blocks if EXT4_MB_HINT_GOAL_ONLY is set Date: Fri, 10 Feb 2023 03:48:07 +0800 Message-Id: <20230209194825.511043-4-shikemeng@huaweicloud.com> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20230209194825.511043-1-shikemeng@huaweicloud.com> References: <20230209194825.511043-1-shikemeng@huaweicloud.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgAn3rEQ3eRjgb0tDQ--.53508S5 X-Coremail-Antispam: 1UD129KBjvdXoWrZFWkJry8trW3tF4UGw48WFg_yoWfJrbEka 4UZr48JayfJF1Ik3WFyrWxKr1IgF95Jr45WrZ5trWfZF1Uua92yw1kJrZ5ZrZrGw43A3sx Cw1UCFy8GrWSvjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbfxYFVCjjxCrM7AC8VAFwI0_Xr0_Wr1l1xkIjI8I6I8E6xAIw20E Y4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l87I20VAvwVAaII0Ic2I_JFv_Gryl82 xGYIkIc2x26280x7IE14v26r1rM28IrcIa0xkI8VCY1x0267AKxVW8JVW5JwA2ocxC64kI II0Yj41l84x0c7CEw4AK67xGY2AK021l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7 xvwVC0I7IYx2IY6xkF7I0E14v26r4UJVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2 z4x0Y4vEx4A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4 xG64xvF2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v2 6r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCF04k20xvY0x0EwI xGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480 Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0I7 IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k2 6cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxV AFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x07jy0PhUUUUU= X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757354606279645563?= X-GMAIL-MSGID: =?utf-8?q?1757354606279645563?= |
Series |
Some bugfix and cleanup to mballoc
|
|
Commit Message
Kemeng Shi
Feb. 9, 2023, 7:48 p.m. UTC
ext4_mb_use_preallocated will ignore the demand to alloc at goal block
only. Return false if EXT4_MB_HINT_GOAL_ONLY is set before use
preallocated blocks in ext4_mb_use_preallocated.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
fs/ext4/mballoc.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Fri, Feb 10, 2023 at 03:48:07AM +0800, Kemeng Shi wrote: > ext4_mb_use_preallocated will ignore the demand to alloc at goal block > only. Return false if EXT4_MB_HINT_GOAL_ONLY is set before use > preallocated blocks in ext4_mb_use_preallocated. > > Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> > --- > fs/ext4/mballoc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c > index 375d9655b525..352ac9139fee 100644 > --- a/fs/ext4/mballoc.c > +++ b/fs/ext4/mballoc.c > @@ -4368,6 +4368,9 @@ ext4_mb_use_preallocated(struct ext4_allocation_context *ac) > if (!(ac->ac_flags & EXT4_MB_HINT_DATA)) > return false; > > + if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)) > + return false; > + > /* first, try per-file preallocation */ > rcu_read_lock(); > list_for_each_entry_rcu(pa, &ei->i_prealloc_list, pa_inode_list) { > -- > 2.30.0 > So with the flag, even when we request for a logical/goal block combination that can be satisfied by one of the inode PAs in the list, we would still exit early and the allocation would eventually fail since the goal block would be marked "in-use" in the buddy. This doesn't seem to be desirable. Maybe instead of exiting early we should try to find a PA that satisfies the logical block we are asking for and then incase of EXT4_MB_HINT_GOAL_ONLY, we can add a check to see if the physical block of the PA corresponds to the goal block. Would like to hear your thoughts on this. Regards, ojaswin
on 2/13/2023 4:38 PM, Ojaswin Mujoo wrote: > On Fri, Feb 10, 2023 at 03:48:07AM +0800, Kemeng Shi wrote: >> ext4_mb_use_preallocated will ignore the demand to alloc at goal block >> only. Return false if EXT4_MB_HINT_GOAL_ONLY is set before use >> preallocated blocks in ext4_mb_use_preallocated. >> >> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> >> --- >> fs/ext4/mballoc.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c >> index 375d9655b525..352ac9139fee 100644 >> --- a/fs/ext4/mballoc.c >> +++ b/fs/ext4/mballoc.c >> @@ -4368,6 +4368,9 @@ ext4_mb_use_preallocated(struct ext4_allocation_context *ac) >> if (!(ac->ac_flags & EXT4_MB_HINT_DATA)) >> return false; >> >> + if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)) >> + return false; >> + >> /* first, try per-file preallocation */ >> rcu_read_lock(); >> list_for_each_entry_rcu(pa, &ei->i_prealloc_list, pa_inode_list) { >> -- >> 2.30.0 >> > So with the flag, even when we request for a logical/goal block > combination that can be satisfied by one of the inode PAs in the list, > we would still exit early and the allocation would eventually fail since > the goal block would be marked "in-use" in the buddy. This doesn't seem > to be desirable. > > Maybe instead of exiting early we should try to find a PA that satisfies > the logical block we are asking for and then incase of > EXT4_MB_HINT_GOAL_ONLY, we can add a check to see if the physical block > of the PA corresponds to the goal block. Would like to hear your > thoughts on this. Yes, this is a more thoughtful, I will improve this in next version. Besides, maybe we should also test length if EXT4_MB_HINT_MERGE is set as ext4_mb_find_by_goal do. > Regards, > ojaswin >
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 375d9655b525..352ac9139fee 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -4368,6 +4368,9 @@ ext4_mb_use_preallocated(struct ext4_allocation_context *ac) if (!(ac->ac_flags & EXT4_MB_HINT_DATA)) return false; + if (unlikely(ac->ac_flags & EXT4_MB_HINT_GOAL_ONLY)) + return false; + /* first, try per-file preallocation */ rcu_read_lock(); list_for_each_entry_rcu(pa, &ei->i_prealloc_list, pa_inode_list) {