Message ID | 20230720094555.1397621-2-chengming.zhou@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp3042252vqt; Thu, 20 Jul 2023 04:17:04 -0700 (PDT) X-Google-Smtp-Source: APBJJlHwETN1DeZX0twMmxEEyPGLnEbAvbY2DAKa0DFA+GiA3WEh7D/A0LFpX74pP7Kx7kAZAsFF X-Received: by 2002:a17:906:280e:b0:988:f93:32e8 with SMTP id r14-20020a170906280e00b009880f9332e8mr4557711ejc.26.1689851824271; Thu, 20 Jul 2023 04:17:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689851824; cv=none; d=google.com; s=arc-20160816; b=0nc5X25inNxiTUsdF9yCFpnbJpFK3iDPiiCLwlkFC6tJyaA1xTCqvWzOCLMWQGESk5 3Afo46IMtfcm7jDQGoAW09hIWV/WTG8S+8Cw03kKItAJYBHz5o+mPb0zFItowWfPsvQk 6RNqMIiLIFDhM/c6SwOFCNEL097U/3ABTt51TGCZUuLzpYAs0o8emkUVIV9T9G4hq+E+ Q5xWYRYDohqcOc0Kh2PxZBXNyYh+dQimsvhLJjg38UsDEUj1CYCbx7VduClkHAfMCRt8 hE/p+G0/st2ycxyASZ0d0kik5dACAQxbVILavkA/nTSjxKQiDGfBQgMg/gILXUGoAxPe qs9Q== 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 :dkim-signature; bh=dQrUdY1vRsj8E+dCm96975wE2JF9r7J+GLmQavXqC6U=; fh=hjJkBnU2szufEu6iYNeHw5+ILtjbq+a6zNGIo+CbvPw=; b=yaA29DB5malJxT6UlP+JpwCwY2ORILKCf5nHqF0VlH4mjiM4YqRSRg0KKiEh+8kTIS MJP21856Hw0qeOLeg3Yx3DRhBTikgnhxyK/Uu59s0pEF5Spd6P0DhATKeOYt1sRgOhEh HzRJv1e2zxKgUIrcmhZEAe9urTtB5XsLsNf15UdQHaa2L/3uDv4rTkd5Qbs9kvkn/sJX J8QuP6pqqMaM095xYdkze5sIujX3nU8hPsyMCLAMrnT7JOShOa/QdDudlm7gpkfCSBQ2 hqBBFWyhiQ0rwHkm4dR71N8nvt8EY0XAVEsZDcMs59nRQ+c7sWGhiUC014gKjEt/lgNJ YR4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=ppP0xq24; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pj27-20020a170906d79b00b00992acfe04b8si554685ejb.150.2023.07.20.04.16.39; Thu, 20 Jul 2023 04:17:04 -0700 (PDT) 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; dkim=pass header.i=@linux.dev header.s=key1 header.b=ppP0xq24; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230319AbjGTJsn (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Thu, 20 Jul 2023 05:48:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47886 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231386AbjGTJsK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 20 Jul 2023 05:48:10 -0400 Received: from out-2.mta0.migadu.com (out-2.mta0.migadu.com [91.218.175.2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FF702704 for <linux-kernel@vger.kernel.org>; Thu, 20 Jul 2023 02:47:16 -0700 (PDT) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1689846435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dQrUdY1vRsj8E+dCm96975wE2JF9r7J+GLmQavXqC6U=; b=ppP0xq24ptj/OlMY3SPOuHL6Ff4dQYJc12lo4pwlHFUru/0kT+yUO+nGANDCOXMijpY0zh 0xRV/YP9illwyEGWdRzcnR+C2a2oqd4/o3nAXfqCCcJ3QCVAM4J4lj3lf7TdGBwhgX25Kc aqsmNNgQe9Mnd4K/gYhs9jp73e9/KfE= From: chengming.zhou@linux.dev To: axboe@kernel.dk, osandov@fb.com, ming.lei@redhat.com, kbusch@kernel.org, krisman@suse.de Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, zhouchengming@bytedance.com Subject: [PATCH 1/6] sbitmap: fix hint wrap in the failure case Date: Thu, 20 Jul 2023 17:45:50 +0800 Message-ID: <20230720094555.1397621-2-chengming.zhou@linux.dev> In-Reply-To: <20230720094555.1397621-1-chengming.zhou@linux.dev> References: <20230720094555.1397621-1-chengming.zhou@linux.dev> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: INBOX X-GMAIL-THRID: 1771938066399285971 X-GMAIL-MSGID: 1771938066399285971 |
Series |
sbitmap: fix offset hint wrap and some optimizations
|
|
Commit Message
Chengming Zhou
July 20, 2023, 9:45 a.m. UTC
From: Chengming Zhou <zhouchengming@bytedance.com> ``` hint = nr + 1; if (hint >= depth - 1) hint = 0; ``` Now we wrap the hint to 0 in the failure case, but: 1. hint == depth - 1, is actually an available offset hint, which we shouldn't wrap hint to 0. 2. In the strict round_robin non-wrap case, we shouldn't wrap at all. ``` wrap = wrap && hint; ``` We only need to check wrap based on the original hint ( > 0), don't need to recheck the new hint which maybe updated in the failure case. Also delete the mismatched comments by the way. Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> --- lib/sbitmap.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
Comments
chengming.zhou@linux.dev writes: > From: Chengming Zhou <zhouchengming@bytedance.com> > > ``` > hint = nr + 1; > if (hint >= depth - 1) > hint = 0; > ``` > > Now we wrap the hint to 0 in the failure case, but: > 1. hint == depth - 1, is actually an available offset hint, which > we shouldn't wrap hint to 0. > 2. In the strict round_robin non-wrap case, we shouldn't wrap at all. > > ``` > wrap = wrap && hint; > ``` > > We only need to check wrap based on the original hint ( > 0), don't need > to recheck the new hint which maybe updated in the failure case. > Also delete the mismatched comments by the way. > > Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> > --- > lib/sbitmap.c | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/lib/sbitmap.c b/lib/sbitmap.c > index eff4e42c425a..5ed6c2adf58e 100644 > --- a/lib/sbitmap.c > +++ b/lib/sbitmap.c > @@ -144,12 +144,7 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, > while (1) { > nr = find_next_zero_bit(word, depth, hint); > if (unlikely(nr >= depth)) { > - /* > - * We started with an offset, and we didn't reset the > - * offset to 0 in a failure case, so start from 0 to > - * exhaust the map. > - */ > - if (hint && wrap) { > + if (wrap) { > hint = 0; > continue; I think this is wrong. If you start with an offset in the wrap case and the bitmap is completely full this will become busy wait until a bit is available. The hint check is what make you break out of the loop early, after wrapping, re-walking the entire bitmap and failing to find any available space. > @@ -160,8 +155,13 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, > break; > > hint = nr + 1; > - if (hint >= depth - 1) > - hint = 0; > + if (hint >= depth) { > + if (wrap) { > + hint = 0; > + continue; > + } > + return -1; > + } > } > > return nr;
On 2023/7/21 03:06, Gabriel Krisman Bertazi wrote: > chengming.zhou@linux.dev writes: > >> From: Chengming Zhou <zhouchengming@bytedance.com> >> >> ``` >> hint = nr + 1; >> if (hint >= depth - 1) >> hint = 0; >> ``` >> >> Now we wrap the hint to 0 in the failure case, but: >> 1. hint == depth - 1, is actually an available offset hint, which >> we shouldn't wrap hint to 0. >> 2. In the strict round_robin non-wrap case, we shouldn't wrap at all. >> >> ``` >> wrap = wrap && hint; >> ``` >> >> We only need to check wrap based on the original hint ( > 0), don't need >> to recheck the new hint which maybe updated in the failure case. >> Also delete the mismatched comments by the way. >> >> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> >> --- >> lib/sbitmap.c | 16 ++++++++-------- >> 1 file changed, 8 insertions(+), 8 deletions(-) >> >> diff --git a/lib/sbitmap.c b/lib/sbitmap.c >> index eff4e42c425a..5ed6c2adf58e 100644 >> --- a/lib/sbitmap.c >> +++ b/lib/sbitmap.c >> @@ -144,12 +144,7 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, >> while (1) { >> nr = find_next_zero_bit(word, depth, hint); >> if (unlikely(nr >= depth)) { >> - /* >> - * We started with an offset, and we didn't reset the >> - * offset to 0 in a failure case, so start from 0 to >> - * exhaust the map. >> - */ >> - if (hint && wrap) { >> + if (wrap) { >> hint = 0; >> continue; > > I think this is wrong. If you start with an offset in the wrap case and > the bitmap is completely full this will become busy wait until a bit is > available. The hint check is what make you break out of the loop early, > after wrapping, re-walking the entire bitmap and failing to find any > available space. Ah yes, you are right, thanks for your explanation. Here we need to check "hint && wrap" to avoid wrap repeatedly. Will drop this change in the next version. > >> @@ -160,8 +155,13 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, >> break; >> >> hint = nr + 1; Here we overwrite hint, may cause repeated wrap. So I think it's clearer that we set "wrap" to false after we wrap? ``` if (wrap) { wrap = false; hint = 0; continue; } ``` Thanks! >> - if (hint >= depth - 1) >> - hint = 0; >> + if (hint >= depth) { >> + if (wrap) { >> + hint = 0; >> + continue; >> + } >> + return -1; >> + } >> } >> >> return nr; >
diff --git a/lib/sbitmap.c b/lib/sbitmap.c index eff4e42c425a..5ed6c2adf58e 100644 --- a/lib/sbitmap.c +++ b/lib/sbitmap.c @@ -144,12 +144,7 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, while (1) { nr = find_next_zero_bit(word, depth, hint); if (unlikely(nr >= depth)) { - /* - * We started with an offset, and we didn't reset the - * offset to 0 in a failure case, so start from 0 to - * exhaust the map. - */ - if (hint && wrap) { + if (wrap) { hint = 0; continue; } @@ -160,8 +155,13 @@ static int __sbitmap_get_word(unsigned long *word, unsigned long depth, break; hint = nr + 1; - if (hint >= depth - 1) - hint = 0; + if (hint >= depth) { + if (wrap) { + hint = 0; + continue; + } + return -1; + } } return nr;