* [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
2025-07-25 7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
@ 2025-07-25 7:05 ` Yu Kuai
2025-07-25 10:21 ` Damien Le Moal
2025-07-25 7:05 ` [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu() Yu Kuai
2025-07-25 7:05 ` [PATCH 3/3] blk-ioc: " Yu Kuai
2 siblings, 1 reply; 7+ messages in thread
From: Yu Kuai @ 2025-07-25 7:05 UTC (permalink / raw)
To: jack, dlemoal, axboe
Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
johnny.chenyi
From: Yu Kuai <yukuai3@huawei.com>
ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
have to be protected by queue_lock, which is too heavy. Hence add a new
helper that is lookless, this is safe because both request_queue and ioc
can be pinged by IO that is still issuing.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
block/blk.h | 1 +
2 files changed, 35 insertions(+)
diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index ce82770c72ab..4945b48dfdb6 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
}
EXPORT_SYMBOL(ioc_lookup_icq);
+/**
+ * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
+ * @q: the associated request_queue
+ *
+ * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called from
+ * io issue path, either return NULL if current issue io to @q for the first
+ * time, or return a valid icq.
+ */
+struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q)
+{
+ struct io_context *ioc = current->io_context;
+ struct io_cq *icq;
+
+ WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
+
+ if (!ioc)
+ return NULL;
+
+ icq = rcu_dereference(ioc->icq_hint);
+ if (icq && icq->q == q)
+ return icq;
+
+ icq = radix_tree_lookup(&ioc->icq_tree, q->id);
+ if (!icq)
+ return NULL;
+
+ if (WARN_ON_ONCE(icq->q != q))
+ return NULL;
+
+ rcu_assign_pointer(ioc->icq_hint, icq);
+ return icq;
+}
+EXPORT_SYMBOL(ioc_lookup_icq_rcu);
+
/**
* ioc_create_icq - create and link io_cq
* @q: request_queue of interest
diff --git a/block/blk.h b/block/blk.h
index 468aa83c5a22..ef31b3ec1c69 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -461,6 +461,7 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
*/
struct io_cq *ioc_find_get_icq(struct request_queue *q);
struct io_cq *ioc_lookup_icq(struct request_queue *q);
+struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
#ifdef CONFIG_BLK_ICQ
void ioc_clear_queue(struct request_queue *q);
#else
--
2.39.2
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
2025-07-25 7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25 10:21 ` Damien Le Moal
2025-07-25 12:03 ` Jan Kara
0 siblings, 1 reply; 7+ messages in thread
From: Damien Le Moal @ 2025-07-25 10:21 UTC (permalink / raw)
To: Yu Kuai, jack, axboe
Cc: linux-block, linux-kernel, yukuai3, yi.zhang, yangerkun,
johnny.chenyi
On 7/25/25 16:05, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@huawei.com>
>
> ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
> have to be protected by queue_lock, which is too heavy. Hence add a new
> helper that is lookless, this is safe because both request_queue and ioc
> can be pinged by IO that is still issuing.
>
> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> ---
> block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
> block/blk.h | 1 +
> 2 files changed, 35 insertions(+)
>
> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> index ce82770c72ab..4945b48dfdb6 100644
> --- a/block/blk-ioc.c
> +++ b/block/blk-ioc.c
> @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
> }
> EXPORT_SYMBOL(ioc_lookup_icq);
>
> +/**
> + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
> + * @q: the associated request_queue
> + *
> + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called from
> + * io issue path, either return NULL if current issue io to @q for the first
> + * time, or return a valid icq.
> + */
> +struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q)
> +{
> + struct io_context *ioc = current->io_context;
> + struct io_cq *icq;
> +
> + WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
I do not think this is necessary.
> +
> + if (!ioc)
> + return NULL;
> +
> + icq = rcu_dereference(ioc->icq_hint);
> + if (icq && icq->q == q)
> + return icq;
> +
> + icq = radix_tree_lookup(&ioc->icq_tree, q->id);
> + if (!icq)
> + return NULL;
> +
> + if (WARN_ON_ONCE(icq->q != q))
> + return NULL;
> +
> + rcu_assign_pointer(ioc->icq_hint, icq);
> + return icq;
> +}
> +EXPORT_SYMBOL(ioc_lookup_icq_rcu);
Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
read lock here inside this function ? That is how ioc_lookup_icq() was doing
things, with code that is more compact than this.
And since ioc_lookup_icq() was already using RCU, it seems that the only change
you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
function to endup with the same above functionality. So why all the churn ?
Another question is: is it safe to call radix_tree_lookup() without any lock
held ? What if this races with a radix tree insertion ? (I may be wrong here as
I am not familiar with that code).
> +
> /**
> * ioc_create_icq - create and link io_cq
> * @q: request_queue of interest
> diff --git a/block/blk.h b/block/blk.h
> index 468aa83c5a22..ef31b3ec1c69 100644
> --- a/block/blk.h
> +++ b/block/blk.h
> @@ -461,6 +461,7 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
> */
> struct io_cq *ioc_find_get_icq(struct request_queue *q);
> struct io_cq *ioc_lookup_icq(struct request_queue *q);
> +struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
> #ifdef CONFIG_BLK_ICQ
> void ioc_clear_queue(struct request_queue *q);
> #else
--
Damien Le Moal
Western Digital Research
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
2025-07-25 10:21 ` Damien Le Moal
@ 2025-07-25 12:03 ` Jan Kara
2025-07-25 17:46 ` Yu Kuai
0 siblings, 1 reply; 7+ messages in thread
From: Jan Kara @ 2025-07-25 12:03 UTC (permalink / raw)
To: Damien Le Moal
Cc: Yu Kuai, jack, axboe, linux-block, linux-kernel, yukuai3,
yi.zhang, yangerkun, johnny.chenyi
On Fri 25-07-25 19:21:06, Damien Le Moal wrote:
> On 7/25/25 16:05, Yu Kuai wrote:
> > From: Yu Kuai <yukuai3@huawei.com>
> >
> > ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
> > have to be protected by queue_lock, which is too heavy. Hence add a new
> > helper that is lookless, this is safe because both request_queue and ioc
> > can be pinged by IO that is still issuing.
> >
> > Signed-off-by: Yu Kuai <yukuai3@huawei.com>
> > ---
> > block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
> > block/blk.h | 1 +
> > 2 files changed, 35 insertions(+)
> >
> > diff --git a/block/blk-ioc.c b/block/blk-ioc.c
> > index ce82770c72ab..4945b48dfdb6 100644
> > --- a/block/blk-ioc.c
> > +++ b/block/blk-ioc.c
> > @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
> > }
> > EXPORT_SYMBOL(ioc_lookup_icq);
> >
> > +/**
> > + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
> > + * @q: the associated request_queue
> > + *
> > + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called from
> > + * io issue path, either return NULL if current issue io to @q for the first
> > + * time, or return a valid icq.
> > + */
> > +struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q)
> > +{
> > + struct io_context *ioc = current->io_context;
> > + struct io_cq *icq;
> > +
> > + WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
>
> I do not think this is necessary.
>
> > +
> > + if (!ioc)
> > + return NULL;
> > +
> > + icq = rcu_dereference(ioc->icq_hint);
> > + if (icq && icq->q == q)
> > + return icq;
> > +
> > + icq = radix_tree_lookup(&ioc->icq_tree, q->id);
> > + if (!icq)
> > + return NULL;
> > +
> > + if (WARN_ON_ONCE(icq->q != q))
> > + return NULL;
> > +
> > + rcu_assign_pointer(ioc->icq_hint, icq);
> > + return icq;
> > +}
> > +EXPORT_SYMBOL(ioc_lookup_icq_rcu);
>
> Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
> read lock here inside this function ? That is how ioc_lookup_icq() was doing
> things, with code that is more compact than this.
>
> And since ioc_lookup_icq() was already using RCU, it seems that the only change
> you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
> function to endup with the same above functionality. So why all the churn ?
Yes, I agree, just dropping the assert and updating callers should be fine.
> Another question is: is it safe to call radix_tree_lookup() without any lock
> held ? What if this races with a radix tree insertion ? (I may be wrong here as
> I am not familiar with that code).
Yes, radix_tree_lookup() is fine to call with just rcu protection.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu()
2025-07-25 12:03 ` Jan Kara
@ 2025-07-25 17:46 ` Yu Kuai
0 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25 17:46 UTC (permalink / raw)
To: Jan Kara, Damien Le Moal
Cc: Yu Kuai, axboe, linux-block, linux-kernel, yukuai3, yi.zhang,
yangerkun, johnny.chenyi
Hi,
在 2025/7/25 20:03, Jan Kara 写道:
> On Fri 25-07-25 19:21:06, Damien Le Moal wrote:
>> On 7/25/25 16:05, Yu Kuai wrote:
>>> From: Yu Kuai <yukuai3@huawei.com>
>>>
>>> ioc_lookup_icq() is used by bfq to lookup bfqq from IO path, the helper
>>> have to be protected by queue_lock, which is too heavy. Hence add a new
>>> helper that is lookless, this is safe because both request_queue and ioc
>>> can be pinged by IO that is still issuing.
>>>
>>> Signed-off-by: Yu Kuai <yukuai3@huawei.com>
>>> ---
>>> block/blk-ioc.c | 34 ++++++++++++++++++++++++++++++++++
>>> block/blk.h | 1 +
>>> 2 files changed, 35 insertions(+)
>>>
>>> diff --git a/block/blk-ioc.c b/block/blk-ioc.c
>>> index ce82770c72ab..4945b48dfdb6 100644
>>> --- a/block/blk-ioc.c
>>> +++ b/block/blk-ioc.c
>>> @@ -343,6 +343,40 @@ struct io_cq *ioc_lookup_icq(struct request_queue *q)
>>> }
>>> EXPORT_SYMBOL(ioc_lookup_icq);
>>>
>>> +/**
>>> + * ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
>>> + * @q: the associated request_queue
>>> + *
>>> + * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called from
>>> + * io issue path, either return NULL if current issue io to @q for the first
>>> + * time, or return a valid icq.
>>> + */
>>> +struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q)
>>> +{
>>> + struct io_context *ioc = current->io_context;
>>> + struct io_cq *icq;
>>> +
>>> + WARN_ON_ONCE(percpu_ref_is_zero(&q->q_usage_counter));
>> I do not think this is necessary.
This is used to indicate this is from IO issue path, I can remove it.
>>> +
>>> + if (!ioc)
>>> + return NULL;
>>> +
>>> + icq = rcu_dereference(ioc->icq_hint);
>>> + if (icq && icq->q == q)
>>> + return icq;
>>> +
>>> + icq = radix_tree_lookup(&ioc->icq_tree, q->id);
>>> + if (!icq)
>>> + return NULL;
>>> +
>>> + if (WARN_ON_ONCE(icq->q != q))
>>> + return NULL;
>>> +
>>> + rcu_assign_pointer(ioc->icq_hint, icq);
>>> + return icq;
>>> +}
>>> +EXPORT_SYMBOL(ioc_lookup_icq_rcu);
>> Patch 2 calls this function with the rcu_read_lock() held. Why not move that rcu
>> read lock here inside this function ? That is how ioc_lookup_icq() was doing
>> things, with code that is more compact than this.
>>
>> And since ioc_lookup_icq() was already using RCU, it seems that the only change
>> you need is to remove the "lockdep_assert_held(&q->queue_lock);" from that
>> function to endup with the same above functionality. So why all the churn ?
> Yes, I agree, just dropping the assert and updating callers should be fine.
Yes, this is much simpler.
>> Another question is: is it safe to call radix_tree_lookup() without any lock
>> held ? What if this races with a radix tree insertion ? (I may be wrong here as
>> I am not familiar with that code).
> Yes, radix_tree_lookup() is fine to call with just rcu protection.
The insertion is protected by queue_lock, and look up is fine with rcu
protection.
Thanks,
Kuai
>
> Honza
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu()
2025-07-25 7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
2025-07-25 7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25 7:05 ` Yu Kuai
2025-07-25 7:05 ` [PATCH 3/3] blk-ioc: " Yu Kuai
2 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25 7:05 UTC (permalink / raw)
To: jack, dlemoal, axboe
Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
johnny.chenyi
From: Yu Kuai <yukuai3@huawei.com>
ioc_lookup_icq() are all called from IO issue path with queue_lock held,
convert to use ioc_lookup_icq_rcu() to get rid of the disk level spin
lock.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
block/bfq-iosched.c | 23 ++++++-----------------
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
index 0cb1e9873aab..b3b9dbbc16d2 100644
--- a/block/bfq-iosched.c
+++ b/block/bfq-iosched.c
@@ -454,17 +454,13 @@ static struct bfq_io_cq *icq_to_bic(struct io_cq *icq)
*/
static struct bfq_io_cq *bfq_bic_lookup(struct request_queue *q)
{
- struct bfq_io_cq *icq;
- unsigned long flags;
-
- if (!current->io_context)
- return NULL;
+ struct io_cq *icq;
- spin_lock_irqsave(&q->queue_lock, flags);
- icq = icq_to_bic(ioc_lookup_icq(q));
- spin_unlock_irqrestore(&q->queue_lock, flags);
+ rcu_read_lock();
+ icq = ioc_lookup_icq_rcu(q);
+ rcu_read_unlock();
- return icq;
+ return icq_to_bic(icq);
}
/*
@@ -2457,15 +2453,8 @@ static bool bfq_bio_merge(struct request_queue *q, struct bio *bio,
unsigned int nr_segs)
{
struct bfq_data *bfqd = q->elevator->elevator_data;
- struct request *free = NULL;
- /*
- * bfq_bic_lookup grabs the queue_lock: invoke it now and
- * store its return value for later use, to avoid nesting
- * queue_lock inside the bfqd->lock. We assume that the bic
- * returned by bfq_bic_lookup does not go away before
- * bfqd->lock is taken.
- */
struct bfq_io_cq *bic = bfq_bic_lookup(q);
+ struct request *free = NULL;
bool ret;
spin_lock_irq(&bfqd->lock);
--
2.39.2
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 3/3] blk-ioc: convert to use ioc_lookup_icq_rcu()
2025-07-25 7:05 [PATCH 0/3] blk-ioc: convert ioc_lookup_icq() to lockless version Yu Kuai
2025-07-25 7:05 ` [PATCH 1/3] blk-ioc: add a new helper ioc_lookup_icq_rcu() Yu Kuai
2025-07-25 7:05 ` [PATCH 2/3] block, bfq: convert to use ioc_lookup_icq_rcu() Yu Kuai
@ 2025-07-25 7:05 ` Yu Kuai
2 siblings, 0 replies; 7+ messages in thread
From: Yu Kuai @ 2025-07-25 7:05 UTC (permalink / raw)
To: jack, dlemoal, axboe
Cc: linux-block, linux-kernel, yukuai3, yukuai1, yi.zhang, yangerkun,
johnny.chenyi
From: Yu Kuai <yukuai3@huawei.com>
Now ioc_lookup_icq() is only called from bfq_prepare_request() from
IO issue path, if it's the first time current issue IO to the disk,
'queue_lock' will be held to creat new icq, otherwise it's safe to
use the new helper. Noted if multiple task share one ioc, and
ioc_create_icq() raced, queue_lock is used to serialize them and only
the first one can succeed inserting icq to ioc.
Also remove ioc_lookup_icq() that is not used now.
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
---
block/blk-ioc.c | 44 ++++----------------------------------------
block/blk.h | 1 -
2 files changed, 4 insertions(+), 41 deletions(-)
diff --git a/block/blk-ioc.c b/block/blk-ioc.c
index 4945b48dfdb6..27dd65957853 100644
--- a/block/blk-ioc.c
+++ b/block/blk-ioc.c
@@ -307,42 +307,6 @@ int __copy_io(unsigned long clone_flags, struct task_struct *tsk)
}
#ifdef CONFIG_BLK_ICQ
-/**
- * ioc_lookup_icq - lookup io_cq from ioc
- * @q: the associated request_queue
- *
- * Look up io_cq associated with @ioc - @q pair from @ioc. Must be called
- * with @q->queue_lock held.
- */
-struct io_cq *ioc_lookup_icq(struct request_queue *q)
-{
- struct io_context *ioc = current->io_context;
- struct io_cq *icq;
-
- lockdep_assert_held(&q->queue_lock);
-
- /*
- * icq's are indexed from @ioc using radix tree and hint pointer,
- * both of which are protected with RCU. All removals are done
- * holding both q and ioc locks, and we're holding q lock - if we
- * find a icq which points to us, it's guaranteed to be valid.
- */
- rcu_read_lock();
- icq = rcu_dereference(ioc->icq_hint);
- if (icq && icq->q == q)
- goto out;
-
- icq = radix_tree_lookup(&ioc->icq_tree, q->id);
- if (icq && icq->q == q)
- rcu_assign_pointer(ioc->icq_hint, icq); /* allowed to race */
- else
- icq = NULL;
-out:
- rcu_read_unlock();
- return icq;
-}
-EXPORT_SYMBOL(ioc_lookup_icq);
-
/**
* ioc_lookup_icq_rcu - lookup io_cq from ioc in io path
* @q: the associated request_queue
@@ -420,7 +384,7 @@ static struct io_cq *ioc_create_icq(struct request_queue *q)
et->ops.init_icq(icq);
} else {
kmem_cache_free(et->icq_cache, icq);
- icq = ioc_lookup_icq(q);
+ icq = ioc_lookup_icq_rcu(q);
if (!icq)
printk(KERN_ERR "cfq: icq link failed!\n");
}
@@ -454,9 +418,9 @@ struct io_cq *ioc_find_get_icq(struct request_queue *q)
} else {
get_io_context(ioc);
- spin_lock_irq(&q->queue_lock);
- icq = ioc_lookup_icq(q);
- spin_unlock_irq(&q->queue_lock);
+ rcu_read_lock();
+ icq = ioc_lookup_icq_rcu(q);
+ rcu_read_unlock();
}
if (!icq) {
diff --git a/block/blk.h b/block/blk.h
index ef31b3ec1c69..3c078e517d59 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -460,7 +460,6 @@ static inline void req_set_nomerge(struct request_queue *q, struct request *req)
* Internal io_context interface
*/
struct io_cq *ioc_find_get_icq(struct request_queue *q);
-struct io_cq *ioc_lookup_icq(struct request_queue *q);
struct io_cq *ioc_lookup_icq_rcu(struct request_queue *q);
#ifdef CONFIG_BLK_ICQ
void ioc_clear_queue(struct request_queue *q);
--
2.39.2
^ permalink raw reply related [flat|nested] 7+ messages in thread