From: Christoph Hellwig <hch@lst.de>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, 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>,
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: [PATCH 03/15] block: add an API to atomically update queue limits
Date: Tue, 23 Jan 2024 09:44:49 +0100 [thread overview]
Message-ID: <20240123084449.GB29041@lst.de> (raw)
In-Reply-To: <01765807-d010-422b-97a6-3171265f36be@kernel.org>
On Tue, Jan 23, 2024 at 01:50:32PM +0900, Damien Le Moal wrote:
> > + return -EINVAL;
> > + return 0;
> > + }
> > +
> > + if (WARN_ON_ONCE(!IS_ENABLED(CONFIG_BLK_DEV_ZONED)))
> > + return -EINVAL;
> > +
> > + if (lim->zone_write_granularity < lim->logical_block_size)
> > + lim->zone_write_granularity = lim->logical_block_size;
>
> This check and change needs to be against the physical block size. Otherwise,
> SMR drives will choke on it.
It probably should, but this mirrors what is done in
blk_queue_zone_write_granularity. And I want to match that behavior
at least for now, we can then improve and document it once this is
the only interface to validate the limits.
> > +
> > + if (lim->max_zone_append_sectors) {
> > + if (WARN_ON_ONCE(!lim->chunk_sectors))
> > + return -EINVAL;
>
> chunk_sectors is the zone size. So we should probably check that it is set after
> the IS_ENABLED() check earlier in the function, no ?
Possibly. In fact I'm wondering where the check comes from, as we
don't seem to have it in the existing helpers.
> > + if (!lim->logical_block_size)
> > + lim->logical_block_size = SECTOR_SIZE;
> > +
> > + if (!lim->physical_block_size)
> > + lim->physical_block_size = SECTOR_SIZE;
> > + if (lim->physical_block_size < lim->logical_block_size)
> > + lim->physical_block_size = lim->physical_block_size;
> > +
> > + if (!lim->io_min)
> > + lim->io_min = SECTOR_SIZE;
>
> This should be lim->logical_block_size, no ?
This comes from the default in blk_set_default_limits.
>
> > + if (lim->io_min < lim->physical_block_size)
> > + lim->io_min = lim->physical_block_size;
>
> But then given that log <= phys, you could set io_min to physical_block_size if
> it is not set.
Which is what we do here, so the above is actually redundant and
can be removed.
> > + if (!lim->max_hw_sectors)
> > + lim->max_hw_sectors = BLK_SAFE_MAX_SECTORS;
> > + if (WARN_ON_ONCE(lim->max_hw_sectors < PAGE_SIZE / SECTOR_SIZE))
>
> You can use PAGE_SECTORS here.
Yes.
next prev parent reply other threads:[~2024-01-23 8:44 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 17:36 atomic queue limits updates Christoph Hellwig
2024-01-22 17:36 ` [PATCH 01/15] block: move max_{open,active}_zones to struct queue_limits Christoph Hellwig
2024-01-23 4:39 ` Damien Le Moal
2024-01-24 6:00 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 02/15] block: refactor disk_update_readahead Christoph Hellwig
2024-01-23 4:41 ` Damien Le Moal
2024-01-23 8:40 ` Christoph Hellwig
2024-01-24 6:01 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 03/15] block: add an API to atomically update queue limits Christoph Hellwig
2024-01-23 4:50 ` Damien Le Moal
2024-01-23 8:44 ` Christoph Hellwig [this message]
2024-01-24 6:08 ` Hannes Reinecke
2024-01-24 9:21 ` Christoph Hellwig
2024-01-25 10:28 ` John Garry
2024-01-25 14:35 ` Christoph Hellwig
2024-01-22 17:36 ` [PATCH 04/15] block: use queue_limits_commit_update in queue_max_sectors_store Christoph Hellwig
2024-01-23 5:07 ` Damien Le Moal
2024-01-24 6:09 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 05/15] block: add a max_user_discard_sectors queue limit Christoph Hellwig
2024-01-22 18:27 ` Keith Busch
2024-01-22 18:38 ` Christoph Hellwig
2024-01-24 15:44 ` Keith Busch
2024-01-25 8:12 ` Christoph Hellwig
2024-01-24 6:10 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 06/15] nvme: remove the hack to not update the discard limits in nvme_config_discard Christoph Hellwig
2024-01-23 5:12 ` Damien Le Moal
2024-01-23 8:45 ` Christoph Hellwig
2024-01-24 6:11 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 07/15] block: use queue_limits_commit_update in queue_discard_max_store Christoph Hellwig
2024-01-23 5:16 ` Damien Le Moal
2024-01-24 6:12 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 08/15] block: pass a queue_limits argument to blk_alloc_queue Christoph Hellwig
2024-01-23 5:17 ` Damien Le Moal
2024-01-24 6:14 ` Hannes Reinecke
2024-01-25 9:45 ` John Garry
2024-01-25 14:32 ` Christoph Hellwig
2024-01-22 17:36 ` [PATCH 09/15] block: pass a queue_limits argument to blk_mq_init_queue Christoph Hellwig
2024-01-23 5:19 ` Damien Le Moal
2024-01-24 6:16 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 10/15] block: pass a queue_limits argument to blk_mq_alloc_disk Christoph Hellwig
2024-01-23 5:22 ` Damien Le Moal
2024-01-24 6:17 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 11/15] virtio_blk: split virtblk_probe Christoph Hellwig
2024-01-23 5:26 ` Damien Le Moal
2024-01-23 14:16 ` Stefan Hajnoczi
2024-01-23 20:23 ` Chaitanya Kulkarni
2024-01-24 6:19 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 12/15] virtio_blk: pass queue_limits to blk_mq_alloc_disk Christoph Hellwig
2024-01-23 5:27 ` Damien Le Moal
2024-01-23 14:19 ` Stefan Hajnoczi
2024-01-24 6:21 ` Hannes Reinecke
2024-06-28 14:25 ` John Garry
2024-06-29 5:19 ` Christoph Hellwig
2024-06-30 9:55 ` John Garry
2024-07-01 4:54 ` Christoph Hellwig
2024-01-22 17:36 ` [PATCH 13/15] loop: cleanup loop_config_discard Christoph Hellwig
2024-01-23 5:28 ` Damien Le Moal
2024-01-24 5:29 ` Chaitanya Kulkarni
2024-01-24 6:21 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 14/15] loop: pass queue_limits to blk_mq_alloc_disk Christoph Hellwig
2024-01-23 5:29 ` Damien Le Moal
2024-01-24 6:22 ` Hannes Reinecke
2024-01-22 17:36 ` [PATCH 15/15] loop: use the atomic queue limits update API Christoph Hellwig
2024-01-23 5:31 ` Damien Le Moal
2024-01-24 6:22 ` Hannes Reinecke
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=20240123084449.GB29041@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=dlemoal@kernel.org \
--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).