From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: John Garry <john.g.garry@oracle.com>,
axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me,
jejb@linux.ibm.com, martin.petersen@oracle.com,
djwong@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org,
dchinner@redhat.com, jack@suse.cz
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, tytso@mit.edu, jbongio@google.com,
linux-scsi@vger.kernel.org, ming.lei@redhat.com,
ojaswin@linux.ibm.com, bvanassche@acm.org,
John Garry <john.g.garry@oracle.com>
Subject: Re: [PATCH v3 02/15] block: Limit atomic writes according to bio and queue limits
Date: Tue, 13 Feb 2024 10:03:58 +0530 [thread overview]
Message-ID: <87h6idugnd.fsf@doe.com> (raw)
In-Reply-To: <20240124113841.31824-3-john.g.garry@oracle.com>
John Garry <john.g.garry@oracle.com> writes:
> We rely the block layer always being able to send a bio of size
> atomic_write_unit_max without being required to split it due to request
> queue or other bio limits.
>
> A bio may contain min(BIO_MAX_VECS, limits->max_segments) vectors on the
> relevant submission paths for atomic writes and each vector contains at
> least a PAGE_SIZE, apart from the first and last vectors.
>
> Signed-off-by: John Garry <john.g.garry@oracle.com>
> ---
> block/blk-settings.c | 28 ++++++++++++++++++++++++++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 11c0361c2313..176f26374abc 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -108,18 +108,42 @@ void blk_queue_bounce_limit(struct request_queue *q, enum blk_bounce bounce)
> }
> EXPORT_SYMBOL(blk_queue_bounce_limit);
>
> +
> +/*
> + * Returns max guaranteed sectors which we can fit in a bio. For convenience of
> + * users, rounddown_pow_of_two() the return value.
> + *
> + * We always assume that we can fit in at least PAGE_SIZE in a segment, apart
> + * from first and last segments.
> + */
It took sometime to really understand what is special about the first
and the last vector. Looks like what we are discussing here is the
I/O covering a partial page, i.e. the starting offset and the end
boundary might not cover the whole page.
It still isn't very clear that why do we need to consider
queue_logical_block_size(q) and not the PAGE_SIZE for those 2 vectors
(1. given atomic writes starting offset and length has alignment
restrictions?
2. So maybe there are devices with starting offset alignment
to be as low as sector size?)
But either ways, my point is it would be good to have a comment above
this function to help understand what is going on here.
> +static unsigned int blk_queue_max_guaranteed_bio_sectors(
> + struct queue_limits *limits,
> + struct request_queue *q)
> +{
> + unsigned int max_segments = min(BIO_MAX_VECS, limits->max_segments);
> + unsigned int length;
> +
> + length = min(max_segments, 2) * queue_logical_block_size(q);
> + if (max_segments > 2)
> + length += (max_segments - 2) * PAGE_SIZE;
> +
> + return rounddown_pow_of_two(length >> SECTOR_SHIFT);
> +}
> +
> static void blk_atomic_writes_update_limits(struct request_queue *q)
> {
> struct queue_limits *limits = &q->limits;
> unsigned int max_hw_sectors =
> rounddown_pow_of_two(limits->max_hw_sectors);
> + unsigned int unit_limit = min(max_hw_sectors,
> + blk_queue_max_guaranteed_bio_sectors(limits, q));
>
> limits->atomic_write_max_sectors =
> min(limits->atomic_write_hw_max_sectors, max_hw_sectors);
> limits->atomic_write_unit_min_sectors =
> - min(limits->atomic_write_hw_unit_min_sectors, max_hw_sectors);
> + min(limits->atomic_write_hw_unit_min_sectors, unit_limit);
> limits->atomic_write_unit_max_sectors =
> - min(limits->atomic_write_hw_unit_max_sectors, max_hw_sectors);
> + min(limits->atomic_write_hw_unit_max_sectors, unit_limit);
> }
>
> /**
> --
> 2.31.1
next prev parent reply other threads:[~2024-02-13 4:34 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 11:38 [PATCH v3 00/15] block atomic writes John Garry
2024-01-24 11:38 ` [PATCH v3 01/15] block: Add atomic write operations to request_queue limits John Garry
2024-02-13 6:22 ` Christoph Hellwig
2024-01-24 11:38 ` [PATCH v3 02/15] block: Limit atomic writes according to bio and queue limits John Garry
2024-02-13 4:33 ` Ritesh Harjani [this message]
2024-02-13 8:05 ` John Garry
2024-01-24 11:38 ` [PATCH v3 03/15] fs/bdev: Add atomic write support info to statx John Garry
2024-01-24 11:38 ` [PATCH v3 04/15] fs: Add RWF_ATOMIC and IOCB_ATOMIC flags for atomic write support John Garry
2024-01-24 11:38 ` [PATCH v3 05/15] block: Add REQ_ATOMIC flag John Garry
2024-02-13 6:24 ` Christoph Hellwig
2024-01-24 11:38 ` [PATCH v3 06/15] block: Pass blk_queue_get_max_sectors() a request pointer John Garry
2024-02-13 6:23 ` Christoph Hellwig
2024-02-13 8:15 ` John Garry
2024-01-24 11:38 ` [PATCH v3 07/15] block: Limit atomic write IO size according to atomic_write_max_sectors John Garry
2024-02-13 6:26 ` Christoph Hellwig
2024-02-13 8:15 ` John Garry
2024-02-14 7:26 ` Christoph Hellwig
2024-02-14 9:24 ` John Garry
2024-01-24 11:38 ` [PATCH v3 08/15] block: Error an attempt to split an atomic write bio John Garry
2024-01-24 11:38 ` [PATCH v3 09/15] block: Add checks to merging of atomic writes John Garry
2024-02-12 10:54 ` Nilay Shroff
2024-02-12 11:20 ` [PATCH " John Garry
2024-02-12 12:01 ` Nilay Shroff
2024-02-12 12:09 ` John Garry
2024-02-13 6:52 ` Nilay Shroff
2024-01-24 11:38 ` [PATCH v3 10/15] block: Add fops atomic write support John Garry
2024-02-13 9:36 ` Nilay Shroff
2024-02-13 9:58 ` [PATCH " John Garry
2024-02-13 11:08 ` Nilay Shroff
2024-02-13 11:52 ` John Garry
2024-02-14 9:38 ` Nilay Shroff
2024-02-14 11:29 ` John Garry
2024-02-14 11:47 ` Nilay Shroff
2024-01-24 11:38 ` [PATCH v3 11/15] scsi: sd: Support reading atomic write properties from block limits VPD John Garry
2024-02-13 6:31 ` Christoph Hellwig
2024-02-13 8:16 ` John Garry
2024-01-24 11:38 ` [PATCH v3 12/15] scsi: sd: Add WRITE_ATOMIC_16 support John Garry
2024-01-24 11:38 ` [PATCH v3 13/15] scsi: scsi_debug: Atomic write support John Garry
2024-01-24 11:38 ` [PATCH v3 14/15] nvme: Support atomic writes John Garry
2024-02-13 6:42 ` Christoph Hellwig
2024-02-13 14:21 ` John Garry
2024-02-14 8:00 ` Christoph Hellwig
2024-02-14 9:21 ` John Garry
2024-02-14 12:27 ` Nilay Shroff
2024-02-14 13:02 ` John Garry
2024-02-14 16:45 ` Nilay Shroff
2024-01-24 11:38 ` [PATCH v3 15/15] nvme: Ensure atomic writes will be executed atomically John Garry
2024-01-25 0:52 ` Keith Busch
2024-01-25 11:28 ` John Garry
2024-01-29 6:20 ` Christoph Hellwig
2024-01-29 9:36 ` John Garry
2024-01-29 14:39 ` Christoph Hellwig
2024-01-26 3:50 ` Chaitanya Kulkarni
2024-02-13 6:42 ` Christoph Hellwig
2024-02-13 14:07 ` John Garry
2024-01-29 6:18 ` [PATCH v3 00/15] block atomic writes Christoph Hellwig
2024-01-29 9:17 ` John Garry
2024-02-06 18:44 ` John Garry
2024-02-10 12:12 ` David Laight
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=87h6idugnd.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=bvanassche@acm.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jbongio@google.com \
--cc=jejb@linux.ibm.com \
--cc=john.g.garry@oracle.com \
--cc=kbusch@kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ming.lei@redhat.com \
--cc=ojaswin@linux.ibm.com \
--cc=sagi@grimberg.me \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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).