From nobody Tue Apr 28 03:56:33 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 49425C433EF for ; Mon, 6 Jun 2022 15:53:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241315AbiFFPxU (ORCPT ); Mon, 6 Jun 2022 11:53:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40574 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241309AbiFFPxQ (ORCPT ); Mon, 6 Jun 2022 11:53:16 -0400 Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0C902226CE1 for ; Mon, 6 Jun 2022 08:53:15 -0700 (PDT) Received: by mail-pf1-x42d.google.com with SMTP id p8so13034888pfh.8 for ; Mon, 06 Jun 2022 08:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Hc9viEeZffCjBHu/ML1+/iUUNsF5FvYmtO3dN3G4Vlw=; b=ewoiGIcHnngJ8XnuyY2jIwN2ChspJyDD06xIEttXPId2yo5q8lZvjdkMTP+UBe/weY 2llWNBnVcx8AlKWfV8HzQcmwXUEEikJ6isuAKerjkF7h7HoyqdjSRO8xEM4H0svFPCf1 YYm/fQbB+1omnCmLIouQIUX9Ms1HRCmablN5JxKM2E0SJsjvbAVKaeap3hqgS77EgLyC RbMeDFbVuSMNqfLaNukLhoRg+UMftSUB7u6b7/k+cvy2G1g1/8y1t5FayjUYqgdxe+/1 FO2YAHgEgvE9y56lNV9ndYqXYVAT5MDoRJjtwsVEm28OmUKzAGFEjQ56U+S7KyUeuOj5 Adlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=Hc9viEeZffCjBHu/ML1+/iUUNsF5FvYmtO3dN3G4Vlw=; b=7I/cQdMMTF0eU6eMZgNURlyvlmEa5j0NEkrUSdH90z/iVrertXcKe013KyG8GiLNin 25QtKI2tNyHHbtyBq0wg/nclzHf2geWjQODwJ+PZ0TUxG9JYjVyVoirPEohkXQ+YN0XH aMn5O4jt9ENkZk76kwFXhty81AQqHABn7C4PMJ/0DwzHYHdtLeFO5ZRkJksB6NZl3jxp yKox8UC76Mn3ehEKxxRYu7RtZCJjnA6TgjsFaQxXwx6NWGLSV7Y0coY+4bez5t2+dxL9 aY9UTbSmv32YDrpsDDhn/gNEysqmuvlyNvl32YTr7Um52bXnG0M5TbbqXHcP1DU0UCJf hmCw== X-Gm-Message-State: AOAM5326TPLHmvWqyGRo6Ok+S9RrND9SH1w/TBNL8fdKY8BA4MaBmiGc uRWw5puFuB7IHRc7yY/iiLglKA== X-Google-Smtp-Source: ABdhPJx0gfs2uBVwDAH9+sv20TF8wBI/O1vbv568hmncRBiTUr/Kng5zHTKiMHbRtDfNJDlNJgm/yA== X-Received: by 2002:a05:6a00:98b:b0:51b:d730:c58 with SMTP id u11-20020a056a00098b00b0051bd7300c58mr21079020pfg.23.1654530794513; Mon, 06 Jun 2022 08:53:14 -0700 (PDT) Received: from C02GD5ZHMD6R.bytedance.net ([139.177.225.255]) by smtp.gmail.com with ESMTPSA id 65-20020a620444000000b0050dc76281dcsm10962951pfe.182.2022.06.06.08.53.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jun 2022 08:53:14 -0700 (PDT) From: Jinke Han X-Google-Original-From: Jinke Han To: tytso@mit.edu, adilger.kernel@dilger.ca Cc: linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, lei.rao@intel.com, hanjinke Subject: [PATCH] ext4: reuse order and buddy in mb_mark_used when buddy split Date: Mon, 6 Jun 2022 23:53:05 +0800 Message-Id: <20220606155305.74146-1-hanjinke.666@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: hanjinke After each buddy split, mb_mark_used will search the proper order for the block which may consume some loop in mb_find_order_for_block. In fact, we can reuse the oder and buddy generated by the buddy split. Reviewed by: lei.rao@intel.com Signed-off-by: hanjinke --- fs/ext4/mballoc.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 9f12f29bc346..c7ac6b269dd8 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -1933,6 +1933,7 @@ static int mb_mark_used(struct ext4_buddy *e4b, struc= t ext4_free_extent *ex) unsigned ret =3D 0; int len0 =3D len; void *buddy; + bool split =3D false; =20 BUG_ON(start + len > (e4b->bd_sb->s_blocksize << 3)); BUG_ON(e4b->bd_group !=3D ex->fe_group); @@ -1957,12 +1958,16 @@ static int mb_mark_used(struct ext4_buddy *e4b, str= uct ext4_free_extent *ex) =20 /* let's maintain buddy itself */ while (len) { - ord =3D mb_find_order_for_block(e4b, start); + if (!split) + ord =3D mb_find_order_for_block(e4b, start); =20 if (((start >> ord) << ord) =3D=3D start && len >=3D (1 << ord)) { /* the whole chunk may be allocated at once! */ mlen =3D 1 << ord; - buddy =3D mb_find_buddy(e4b, ord, &max); + if (!split) + buddy =3D mb_find_buddy(e4b, ord, &max); + else + split =3D false; BUG_ON((start >> ord) >=3D max); mb_set_bit(start >> ord, buddy); e4b->bd_info->bb_counters[ord]--; @@ -1989,6 +1994,7 @@ static int mb_mark_used(struct ext4_buddy *e4b, struc= t ext4_free_extent *ex) mb_clear_bit(cur + 1, buddy); e4b->bd_info->bb_counters[ord]++; e4b->bd_info->bb_counters[ord]++; + split =3D true; } mb_set_largest_free_order(e4b->bd_sb, e4b->bd_info); =20 --=20 2.20.1