virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Xuan Zhuo <xuanzhuo@linux.alibaba.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Damien Le Moal <dlemoal@kernel.org>,
	Keith Busch <kbusch@kernel.org>, Sagi Grimberg <sagi@grimberg.me>,
	linux-block@vger.kernel.org, linux-nvme@lists.infradead.org,
	virtualization@lists.linux.dev
Subject: Re: atomic queue limits updates v3
Date: Thu, 1 Feb 2024 11:24:07 +0800	[thread overview]
Message-ID: <ZbsO1wOD03NVD/9S@fedora> (raw)
In-Reply-To: <20240131130400.625836-1-hch@lst.de>

On Wed, Jan 31, 2024 at 02:03:46PM +0100, Christoph Hellwig wrote:
> Hi Jens,
> 
> currently queue limits updates are a mess in that they are updated one
> limit at a time, which makes both cross-checking them against other
> limits hard, and also makes it hard to provide atomicy.
> 
> This series tries to change this by updating the whole set of queue
> limits atomically.   This in done in two ways:
> 
>  - for the initial setup the queue_limits structure is simply passed to
>    the queue/disk allocation helpers and applies there after validation.
>  - for the (relatively few) cases that update limits at runtime a pair
>    of helpers to take a snapshot of the current limits and to commit it
>    after picking up the callers changes are provided.
> 
> As the series is big enough it only converts two drivers - virtio_blk as
> a heavily used driver in virtualized setups, and loop as one that actually
> does runtime updates while being fairly simple.  I plan to update most
> drivers for this merge window, although SCSI will probably have to wait
> for the next one given that it will need extensive API changes in the
> LLDD and ULD interfaces.
> 
> Chances since v2:
>  - fix the physical block size default
>  - use PAGE_SECTORS_SHIFT more 
> 
> Chances since v1:
>  - remove a spurious NULL return in blk_alloc_queue
>  - keep the existing max_discard_sectors == 0 behavior
>  - drop the patch nvme discard limit update hack - it will go into
>    the series updating nvme instead
>  - drop a chunk_sector check
>  - use PAGE_SECTORS in a few places
>  - document the checks and defaults in blk_validate_limits
>  - various spelling fixes

For the whole series:

Reviewed-by: Ming Lei <ming.lei@redhat.com>

Thanks,
Ming


  parent reply	other threads:[~2024-02-01  3:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 13:03 atomic queue limits updates v3 Christoph Hellwig
2024-01-31 13:03 ` [PATCH 01/14] block: move max_{open,active}_zones to struct queue_limits Christoph Hellwig
2024-01-31 23:10   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 02/14] block: refactor disk_update_readahead Christoph Hellwig
2024-01-31 23:11   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 03/14] block: add an API to atomically update queue limits Christoph Hellwig
2024-01-31 23:14   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 04/14] block: use queue_limits_commit_update in queue_max_sectors_store Christoph Hellwig
2024-01-31 23:18   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 05/14] block: add a max_user_discard_sectors queue limit Christoph Hellwig
2024-01-31 23:28   ` Chaitanya Kulkarni
2024-02-01  0:36   ` Keith Busch
2024-02-01  4:18     ` Christoph Hellwig
2024-01-31 13:03 ` [PATCH 06/14] block: use queue_limits_commit_update in queue_discard_max_store Christoph Hellwig
2024-01-31 23:29   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 07/14] block: pass a queue_limits argument to blk_alloc_queue Christoph Hellwig
2024-01-31 23:32   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 08/14] block: pass a queue_limits argument to blk_mq_init_queue Christoph Hellwig
2024-01-31 23:33   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 09/14] block: pass a queue_limits argument to blk_mq_alloc_disk Christoph Hellwig
2024-01-31 23:36   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 10/14] virtio_blk: split virtblk_probe Christoph Hellwig
2024-01-31 13:03 ` [PATCH 11/14] virtio_blk: pass queue_limits to blk_mq_alloc_disk Christoph Hellwig
2024-01-31 23:37   ` Chaitanya Kulkarni
2024-01-31 13:03 ` [PATCH 12/14] loop: cleanup loop_config_discard Christoph Hellwig
2024-01-31 13:03 ` [PATCH 13/14] loop: pass queue_limits to blk_mq_alloc_disk Christoph Hellwig
2024-01-31 23:38   ` Chaitanya Kulkarni
2024-01-31 13:04 ` [PATCH 14/14] loop: use the atomic queue limits update API Christoph Hellwig
2024-01-31 23:38   ` Chaitanya Kulkarni
2024-01-31 23:26 ` atomic queue limits updates v3 Martin K. Petersen
2024-02-01  7:04   ` Christoph Hellwig
2024-02-01  3:24 ` Ming Lei [this message]
2024-02-01  7:10 ` Christoph Hellwig
2024-02-08 18:29   ` 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=ZbsO1wOD03NVD/9S@fedora \
    --to=ming.lei@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dlemoal@kernel.org \
    --cc=hch@lst.de \
    --cc=jasowang@redhat.com \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=martin.petersen@oracle.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=sagi@grimberg.me \
    --cc=stefanha@redhat.com \
    --cc=virtualization@lists.linux.dev \
    --cc=xuanzhuo@linux.alibaba.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;
as well as URLs for NNTP newsgroup(s).