From patchwork Thu Dec 1 04:54:04 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kemeng Shi X-Patchwork-Id: 28198 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp75984wrr; Wed, 30 Nov 2022 20:55:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf7x6xXi4gK+N3gRn2yKgiAKZCZP6ckSKDOrMSQ3L1Vqvit8/lMFwImtffpppjBzqGDbmR8i X-Received: by 2002:a05:6402:360b:b0:468:f365:dca with SMTP id el11-20020a056402360b00b00468f3650dcamr21998777edb.41.1669870538498; Wed, 30 Nov 2022 20:55:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669870538; cv=none; d=google.com; s=arc-20160816; b=D4lj0MI7lu0gJLT1zmHNNxSkyJ2gNGj1VeMLOgEsAj9TnuRmRhTwFz6WkDio/vR4QL 8Bjmu+/B9Zhjyh0dKHEcDGtOqaI1nmJkqsYRRtzUR4bORLJ5TipKAcqTcOYIgumRwX/l 76NaO7d8pmnL52a/M+SmsLZBb6pRhqYHrh5WV/ov/k2oldPt6bUNVrVN0g0NA7+IoVae AXw5qoPzTQOa8Qgknn9WJTM/O9dh2FPPJA7YeHnbTYRs9/oWc/SadUmIcUcXdPO433sd i8vLdvsx9kLjDFDjmrYyRP2wuc40wF8ful80j32St4+++siymaI9n81y2/vGEusmdD/T pkvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=e2NThQ1/viC7V74zQA9nfcZrj3Re3dxAsOqRN0Rg0FM=; b=MRXlpvsM2ojZzbkecuCF+u3qncf5IY/Yvpc7sE5vxU1gWQ6h4PsB4xoXHR1GND5n1b SdVD6h6Yq7rMycXRwJHxXvn79KYbpjUxpVr0c3Oufvchbvhh1HyOcekDyTZ4yAFY302R DTFWDMtJyz4jV+cyONmUli91sx/ySaTB17Y0Sh99qbnpQmzBZGHmbUDNizBmXtU/yx80 vjFVNgRVKRc9/wC4khXpvREJ/+C0VRLAzTKS97EmSw0JMvDFHxUT6xsxwUI2Ha/1/GEN Rk+U1aPCGQjN31oChzz7LU5b5Z25Z2b1UnJAHgasZydz9dv5RJdNQGb3zYBcado2jVsb BmQA== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q5-20020a056402248500b004676b7d42d7si2927045eda.243.2022.11.30.20.55.14; Wed, 30 Nov 2022 20:55:38 -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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229461AbiLAEzB (ORCPT + 99 others); Wed, 30 Nov 2022 23:55:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229728AbiLAEy5 (ORCPT ); Wed, 30 Nov 2022 23:54:57 -0500 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A58FA9FEC1; Wed, 30 Nov 2022 20:54:56 -0800 (PST) Received: from kwepemi500016.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4NN3cg3ZLbzHwMr; Thu, 1 Dec 2022 12:53:39 +0800 (CST) Received: from huawei.com (10.174.178.129) by kwepemi500016.china.huawei.com (7.221.188.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 1 Dec 2022 12:54:10 +0800 From: Kemeng Shi To: CC: , , , , Subject: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to avoid lost wakeups Date: Thu, 1 Dec 2022 12:54:04 +0800 Message-ID: <20221201045408.21908-2-shikemeng@huawei.com> X-Mailer: git-send-email 2.14.1.windows.1 In-Reply-To: <20221201045408.21908-1-shikemeng@huawei.com> References: <20221201045408.21908-1-shikemeng@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.174.178.129] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemi500016.china.huawei.com (7.221.188.220) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750986169610360402?= X-GMAIL-MSGID: =?utf-8?q?1750986169610360402?= If we decremented queue without waiters, we should not decremente freed bits number "nr", or all "nr" could be consumed in a empty queue and no wakeup will be called. Currently, for case "wait_cnt > 0", "nr" will not be decremented if we decremented queue without watiers and retry is returned to avoid lost wakeups. However for case "wait_cnt == 0", "nr" will be decremented unconditionally and maybe decremented to zero. Although retry is returned by active state of queue, it's not actually executed for "nr" is zero. Fix this by only decrementing "nr" for active queue when "wait_cnt == 0". After this fix, "nr" will always be non-zero when we decremented inactive queue for case "wait_cnt == 0", so the need to retry could be returned by "nr" and active state of waitqueue returned for the same purpose is not needed. Signed-off-by: Kemeng Shi --- lib/sbitmap.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/lib/sbitmap.c b/lib/sbitmap.c index 7280ae8ca88c..e40759bcf821 100644 --- a/lib/sbitmap.c +++ b/lib/sbitmap.c @@ -604,7 +604,6 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq, int *nr) struct sbq_wait_state *ws; unsigned int wake_batch; int wait_cnt, cur, sub; - bool ret; if (*nr <= 0) return false; @@ -632,15 +631,15 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq, int *nr) if (wait_cnt > 0) return !waitqueue_active(&ws->wait); - *nr -= sub; - /* * When wait_cnt == 0, we have to be particularly careful as we are * responsible to reset wait_cnt regardless whether we've actually - * woken up anybody. But in case we didn't wakeup anybody, we still - * need to retry. + * woken up anybody. But in case we didn't wakeup anybody, we should + * not consume nr and need to retry to avoid lost wakeups. */ - ret = !waitqueue_active(&ws->wait); + if (waitqueue_active(&ws->wait)) + *nr -= sub; + wake_batch = READ_ONCE(sbq->wake_batch); /* @@ -669,7 +668,7 @@ static bool __sbq_wake_up(struct sbitmap_queue *sbq, int *nr) sbq_index_atomic_inc(&sbq->wake_index); atomic_set(&ws->wait_cnt, wake_batch); - return ret || *nr; + return *nr; } void sbitmap_queue_wake_up(struct sbitmap_queue *sbq, int nr)