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;
From:   Gabriel Krisman Bertazi <krisman@suse.de>
To:     Kemeng Shi <shikemeng@huawei.com>
Cc:     <axboe@kernel.dk>, <linux-block@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <shikemeng@huaweicloud.com>,
        <linfeilong@huawei.com>, <liuzhiqiang@huawei.com>
Subject: Re: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to
 avoid lost wakeups
References: <20221201045408.21908-1-shikemeng@huawei.com>
        <20221201045408.21908-2-shikemeng@huawei.com>
Date:   Thu, 01 Dec 2022 10:32:36 -0300
In-Reply-To: <20221201045408.21908-2-shikemeng@huawei.com> (Kemeng Shi's
        message of "Thu, 1 Dec 2022 12:54:04 +0800")
Message-ID: <87y1rrmeq3.fsf@suse.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

Kemeng Shi <shikemeng@huawei.com> writes:

> 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.
>

Hi Kemeng,

Fwiw, I sent a patch rewriting this algorithm which is now merged in
axboe/for-next.  It drops the per-waitqueue wait_cnt entirely.  You can
find it here:

https://lore.kernel.org/lkml/20221110153533.go5qs3psm75h27mx@quack3/T/

Thanks!


-- 
Gabriel Krisman Bertazi