From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-block@vger.kernel.org
Cc: axboe@kernel.dk, hch@lst.de, ming.lei@redhat.com, hare@suse.de,
sth@linux.ibm.com, gjoyce@ibm.com, nilay@linux.ibm.com
Subject: [PATCHv8 0/3] block: move sched_tags allocation/de-allocation outside of locking context
Date: Wed, 30 Jul 2025 13:16:06 +0530 [thread overview]
Message-ID: <20250730074614.2537382-1-nilay@linux.ibm.com> (raw)
Hi,
There have been a few reports[1] indicating potential lockdep warnings due
to a lock dependency from the percpu allocator to the elevator lock. This
patch series aims to eliminate that dependency.
The series consists of three patches:
The first patch is preparatory patch and just move elevator queue
allocation logic from ->init_sched into blk_mq_init_sched.
The second patch in the series restructures sched_tags allocation and
deallocation during elevator update/switch operations to ensure these
actions are performed entirely outside the ->freeze_lock and ->elevator_
lock. This eliminates the percpu allocator’s lock dependency on the
elevator and freeze lock during scheduler transitions.
The third patch introduces batch allocation and deallocation helpers for
sched_tags. These helpers are used during __blk_mq_update_nr_hw_queues()
to decouple sched_tags memory management from both the elevator and freeze
locks, addressing the lockdep concerns in the nr_hw_queues update path.
[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/
Changes since v7:
- Rebased code on top of block-6.17, commit 5421681bc3ef ("blk-ioc: don't
hold queue_lock for ioc_lookup_icq()")
Link to v7: https://lore.kernel.org/all/20250701081954.57381-1-nilay@linux.ibm.com/
Changes since v6:
- Add warning when loading elevator tags from an xarray yields nothing
(Hannes Reinecke)
- Use elevator tags instead of xarray table as a function argument to
elv_update_nr_hw_queues (Ming Lei)
Link to v6: https://lore.kernel.org/all/20250630054756.54532-1-nilay@linux.ibm.com/
Changes since v5:
- Fixed smatch warning reported by kernel test robot here:
https://lore.kernel.org/all/202506300509.2S1tygch-lkp@intel.com/
Link to v5: https://lore.kernel.org/all/20250627175544.1063910-1-nilay@linux.ibm.com/
Changes since v4:
- Define a local Xarray variable in __blk_mq_update_nr_hw_queues to store
sched_tags, instead of storing it in an Xarray defined in 'struct elevator_tags'
(Ming Lei)
Link to v4: https://lore.kernel.org/all/20250624131716.630465-1-nilay@linux.ibm.com/
Changes since v3:
- Further split the patchset into three patch series so that we can
have a separate patch for sched_tags batch allocation/deallocation
(Ming Lei)
- Use Xarray to store and load the sched_tags (Ming Lei)
- Unexport elevator_alloc() as we no longer need to use it outside
of block layer core (hch)
- unwind the sched_tags allocation and free tags when we it fails in
the middle of allocation (hch)
- Move struct elevator_queue header from commin header to elevator.c
as there's no user of it outside elevator.c (Ming Lei, hch)
Link to v3: https://lore.kernel.org/all/20250616173233.3803824-1-nilay@linux.ibm.com/
Change since v2:
- Split the patch into a two patch series. The first patch updates
->init_sched elevator API change and second patch handles the sched
tags allocation/de-allocation logic (Ming Lei)
- Address sched tags allocation/deallocation logic while running in the
context of nr_hw_queue update so that we can handle all possible
scenarios in a single patchest (Ming Lei)
Link to v2: https://lore.kernel.org/all/20250528123638.1029700-1-nilay@linux.ibm.com/
Changes since v1:
- As the lifetime of elevator queue and sched tags are same, allocate
and move sched tags under struct elevator_queue (Ming Lei)
Link to v1: https://lore.kernel.org/all/20250520103425.1259712-1-nilay@linux.ibm.com/
Nilay Shroff (3):
block: move elevator queue allocation logic into blk_mq_init_sched
block: fix lockdep warning caused by lock dependency in
elv_iosched_store
block: fix potential deadlock while running nr_hw_queue update
block/bfq-iosched.c | 13 +--
block/blk-mq-sched.c | 223 ++++++++++++++++++++++++++++--------------
block/blk-mq-sched.h | 12 ++-
block/blk-mq.c | 16 ++-
block/blk.h | 4 +-
block/elevator.c | 38 +++++--
block/elevator.h | 16 ++-
block/kyber-iosched.c | 11 +--
block/mq-deadline.c | 14 +--
9 files changed, 228 insertions(+), 119 deletions(-)
--
2.50.1
next reply other threads:[~2025-07-30 7:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 7:46 Nilay Shroff [this message]
2025-07-30 7:46 ` [PATCHv8 1/3] block: move elevator queue allocation logic into blk_mq_init_sched Nilay Shroff
2025-07-30 7:46 ` [PATCHv8 2/3] block: fix lockdep warning caused by lock dependency in elv_iosched_store Nilay Shroff
2025-10-01 5:20 ` [6.16.9 / 6.17.0 PANIC REGRESSION] " Kyle Sanderson
2025-10-01 13:05 ` Kyle Sanderson
2025-10-02 15:30 ` Nilay Shroff
2025-10-02 15:58 ` Jens Axboe
2025-10-02 16:49 ` Linus Torvalds
2025-10-02 16:54 ` Jens Axboe
2025-07-30 7:46 ` [PATCHv8 3/3] block: fix potential deadlock while running nr_hw_queue update Nilay Shroff
2025-07-30 7:48 ` [PATCHv8 0/3] block: move sched_tags allocation/de-allocation outside of locking context Nilay Shroff
2025-07-30 12:21 ` Jens Axboe
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=20250730074614.2537382-1-nilay@linux.ibm.com \
--to=nilay@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=gjoyce@ibm.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=sth@linux.ibm.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.