public inbox for linux-block@vger.kernel.org
 help / color / mirror / Atom feed
From: Nilay Shroff <nilay@linux.ibm.com>
To: linux-block@vger.kernel.org
Cc: ming.lei@redhat.com, hch@lst.de, axboe@kernel.dk,
	sth@linux.ibm.com, gjoyce@ibm.com
Subject: [PATCHv3 0/2] block: move sched_tags allocation/de-allocation outside of locking context
Date: Mon, 16 Jun 2025 23:02:24 +0530	[thread overview]
Message-ID: <20250616173233.3803824-1-nilay@linux.ibm.com> (raw)

There have been few reports suggesting potential lockdep caused due to
the percpu lock dependency on elevator lock. This patchset aims to fix
that dependency.

This patchset contains the two 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 restructure the
sched tags management code so that sched tags allocation and de-allocation
now occurs entirely outside of the ->freeze_lock and ->elevator_lock,
eliminating the percpu lock dependency on elevator lock problem which
could potentially occur during scheduler updates or hardware queue updates.

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 posible
      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 (2):
  block: move elevator queue allocation logic into blk_mq_init_sched
  block: fix lock dependency between percpu alloc lock and elevator lock

 block/bfq-iosched.c   |  13 +--
 block/blk-mq-sched.c  | 247 +++++++++++++++++++++++++++++++-----------
 block/blk-mq-sched.h  |  13 ++-
 block/blk-mq.c        |  14 ++-
 block/blk.h           |   4 +-
 block/elevator.c      |  82 ++++++++++----
 block/elevator.h      |  30 ++++-
 block/kyber-iosched.c |  11 +-
 block/mq-deadline.c   |  14 +--
 9 files changed, 308 insertions(+), 120 deletions(-)

-- 
2.49.0


             reply	other threads:[~2025-06-16 17:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16 17:32 Nilay Shroff [this message]
2025-06-16 17:32 ` [PATCHv3 1/2] block: move elevator queue allocation logic into blk_mq_init_sched Nilay Shroff
2025-06-17 15:07   ` Ming Lei
2025-06-20 14:39     ` Nilay Shroff
2025-06-20 15:17       ` Ming Lei
2025-06-20 16:13         ` Nilay Shroff
2025-06-23  5:56   ` Christoph Hellwig
2025-06-23  9:14     ` Nilay Shroff
2025-06-16 17:32 ` [PATCHv3 2/2] block: fix lock dependency between percpu alloc lock and elevator lock Nilay Shroff
2025-06-18  3:06   ` Ming Lei
2025-06-18  6:52     ` Nilay Shroff
2025-06-23  6:10   ` Christoph Hellwig
2025-06-23  9:33     ` Nilay Shroff
2025-06-23 13:36       ` Christoph Hellwig

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=20250616173233.3803824-1-nilay@linux.ibm.com \
    --to=nilay@linux.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=gjoyce@ibm.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox