From: Hugh Dickins <hughd@google.com>
To: Jan Kara <jack@suse.cz>
Cc: Hugh Dickins <hughd@google.com>, Keith Busch <kbusch@kernel.org>,
Jens Axboe <axboe@kernel.dk>, Yu Kuai <yukuai1@huaweicloud.com>,
Liu Song <liusong@linux.alibaba.com>,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH next] sbitmap: fix lockup while swapping
Date: Tue, 27 Sep 2022 20:56:14 -0700 (PDT) [thread overview]
Message-ID: <2b931ee7-1bc9-e389-9d9f-71eb778dcf1@google.com> (raw)
In-Reply-To: <20220927103123.cvjbdx6lqv7jxa2w@quack3>
On Tue, 27 Sep 2022, Jan Kara wrote:
> On Mon 26-09-22 20:39:03, Hugh Dickins wrote:
>
> So my thinking was that instead of having multiple counters, we'd have just
> two - one counting completions and the other one counting wakeups and if
> completions - wakeups > batch, we search for waiters in the wait queues,
> wake them up so that 'wakeups' counter catches up. That also kind of
> alleviates the 'wake_index' issue because racing updates to it will lead to
> reordering of wakeups but not to lost wakeups, retries, or anything.
>
> I also agree with your wake_up_nr_return() idea below, that is part of this
> solution (reliably waking given number of waiters) and in fact I have
> already coded that yesterday while thinking about the problem ;)
Great - I'm pleasantly surprised to have been not so far off,
and we seem to be much in accord.
(What I called wake_up_nr_return() can perfectly well be wake_up_nr()
itself: I had just been temporarily avoiding a void to int change in
a header file, recompiling the world.)
Many thanks for your detailed elucidation of the batch safety,
in particular: I won't pretend to have absorbed it completely yet,
but it's there in your mail for me and all of us to refer back to.
> > TBH I have not tested this one outside of that experiment: would you
> > prefer this patch to my first one, I test and sign this off and send?
>
> Yes, actually this is an elegant solution. It has the same inherent
> raciness as your waitqueue_active() patch so wakeups could be lost even
> though some waiters need them but that seems pretty unlikely. So yes, if
> you can submit this, I guess this is a good band aid for the coming merge
> window.
No problem in the testing, the v2 patch follows now.
>
> > > 2) Revert Yu Kuai's original fix 040b83fcecfb8 ("sbitmap: fix possible io
> > > hung due to lost wakeup") and my fixup 48c033314f37 ("sbitmap: Avoid leaving
> > > waitqueue in invalid state in __sbq_wake_up()"). But then Keith would have
> > > to redo his batched accounting patches on top.
> >
> > I know much too little to help make that choice.
>
> Yeah, I guess it is Jens' call in the end. I'm fine with both options.
>
> Honza
> --
> Jan Kara <jack@suse.com>
> SUSE Labs, CR
next prev parent reply other threads:[~2022-09-28 3:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-18 21:10 [PATCH next] sbitmap: fix lockup while swapping Hugh Dickins
2022-09-19 21:22 ` Keith Busch
2022-09-19 23:01 ` Hugh Dickins
2022-09-21 16:40 ` Jan Kara
2022-09-23 14:43 ` Jan Kara
2022-09-23 15:13 ` Keith Busch
2022-09-23 16:16 ` Hugh Dickins
2022-09-23 19:07 ` Keith Busch
2022-09-23 21:29 ` Hugh Dickins
2022-09-23 23:15 ` Hugh Dickins
2022-09-26 11:44 ` Jan Kara
2022-09-26 14:08 ` Yu Kuai
2022-09-27 3:39 ` Hugh Dickins
2022-09-27 10:31 ` Jan Kara
2022-09-28 3:56 ` Hugh Dickins [this message]
2022-09-28 3:59 ` [PATCH next v2] " Hugh Dickins
2022-09-28 4:07 ` Hugh Dickins
2022-09-29 8:39 ` Jan Kara
2022-09-29 19:50 ` [PATCH next v3] " Hugh Dickins
2022-09-29 19:56 ` Keith Busch
2022-09-29 23:58 ` Jens Axboe
[not found] ` <20220924023047.1410-1-hdanton@sina.com>
2022-09-27 4:02 ` [PATCH next] " Hugh Dickins
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=2b931ee7-1bc9-e389-9d9f-71eb778dcf1@google.com \
--to=hughd@google.com \
--cc=axboe@kernel.dk \
--cc=jack@suse.cz \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liusong@linux.alibaba.com \
--cc=yukuai1@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.