[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZsQZHZ0y6qMJGaLQ@dread.disaster.area>
Date: Tue, 20 Aug 2024 14:18:37 +1000
From: Dave Chinner <david@...morbit.com>
To: NeilBrown <neilb@...e.de>
Cc: Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 5/9] Block: switch bd_prepare_to_claim to use
___wait_var_event()
On Mon, Aug 19, 2024 at 03:20:39PM +1000, NeilBrown wrote:
> bd_prepare_to_claim() current uses a bit waitqueue with a matching
> wake_up_bit() in bd_clear_claiming(). However it is really waiting on a
> "var", not a "bit".
>
> So change to wake_up_var(), and use ___wait_var_event() for the waiting.
> Using the triple-underscore version allows us to drop the mutex across
> the schedule() call.
....
> @@ -535,33 +535,23 @@ int bd_prepare_to_claim(struct block_device *bdev, void *holder,
> const struct blk_holder_ops *hops)
> {
> struct block_device *whole = bdev_whole(bdev);
> + int err = 0;
>
> if (WARN_ON_ONCE(!holder))
> return -EINVAL;
> -retry:
> - mutex_lock(&bdev_lock);
> - /* if someone else claimed, fail */
> - if (!bd_may_claim(bdev, holder, hops)) {
> - mutex_unlock(&bdev_lock);
> - return -EBUSY;
> - }
> -
> - /* if claiming is already in progress, wait for it to finish */
> - if (whole->bd_claiming) {
> - wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
> - DEFINE_WAIT(wait);
>
> - prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
> - mutex_unlock(&bdev_lock);
> - schedule();
> - finish_wait(wq, &wait);
> - goto retry;
> - }
> + mutex_lock(&bdev_lock);
> + ___wait_var_event(&whole->bd_claiming,
> + (err = bd_may_claim(bdev, holder, hops)) != 0 || !whole->bd_claiming,
> + TASK_UNINTERRUPTIBLE, 0, 0,
> + mutex_unlock(&bdev_lock); schedule(); mutex_lock(&bdev_lock));
That's not an improvement. Instead of nice, obvious, readable code,
I now have to go look at a macro and manually substitute the
parameters to work out what this abomination actually does.
-Dave.
--
Dave Chinner
david@...morbit.com
Powered by blists - more mailing lists