From: Jens Axboe <axboe@kernel.dk>
To: Kemeng Shi <shikemeng@huaweicloud.com>,
Kemeng Shi <shikemeng@huawei.com>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linfeilong@huawei.com, liuzhiqiang@huawei.com
Subject: Re: [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to avoid lost wakeups
Date: Thu, 1 Dec 2022 17:58:47 -0700 [thread overview]
Message-ID: <e6a984e9-f597-d987-2eef-9c3dd8ae7f0e@kernel.dk> (raw)
In-Reply-To: <81e3f861-f163-c17c-49d4-2408f16c3350@huaweicloud.com>
On 12/1/22 12:21?AM, Kemeng Shi wrote:
>
>
> on 12/1/2022 12:54 PM, Kemeng Shi wrote:
>> 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 <shikemeng@huawei.com>
>> ---
>> 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);
> There is a warnning reported by checkpatch.pl which is
> "WARNING:waitqueue_active without comment" but I don't know why.
Most likely because waitqueue_active() could be racy, so a comment is
warranted on why it's safe rather than using wq_has_sleeper().
--
Jens Axboe
next prev parent reply other threads:[~2022-12-02 0:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-01 4:54 [PATCH 0/5] A few cleanup and bugfix patches for sbitmap Kemeng Shi
2022-12-01 4:54 ` [PATCH 1/5] sbitmap: don't consume nr for inactive waitqueue to avoid lost wakeups Kemeng Shi
2022-12-01 7:21 ` Kemeng Shi
2022-12-02 0:58 ` Jens Axboe [this message]
2022-12-02 2:34 ` Kemeng Shi
2022-12-01 13:32 ` Gabriel Krisman Bertazi
2022-12-02 0:57 ` Kemeng Shi
2022-12-01 4:54 ` [PATCH 2/5] sbitmap: remove unnecessary calculation of alloc_hint in __sbitmap_get_shallow Kemeng Shi
2022-12-01 4:54 ` [PATCH 3/5] sbitmap: remove redundant check in __sbitmap_queue_get_batch Kemeng Shi
2022-12-01 4:54 ` [PATCH 4/5] sbitmap: rewrite sbitmap_find_bit_in_index to reduce repeat code Kemeng Shi
2022-12-01 4:54 ` [PATCH 5/5] sbitmap: add sbitmap_find_bit to remove repeat code in __sbitmap_get/__sbitmap_get_shallow Kemeng Shi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e6a984e9-f597-d987-2eef-9c3dd8ae7f0e@kernel.dk \
--to=axboe@kernel.dk \
--cc=linfeilong@huawei.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuzhiqiang@huawei.com \
--cc=shikemeng@huawei.com \
--cc=shikemeng@huaweicloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox