public inbox for [email protected]
 help / color / mirror / Atom feed
From: Hannes Reinecke <[email protected]>
To: John Garry <[email protected]>,
	[email protected], [email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected]
Cc: [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected],
	[email protected], [email protected], [email protected],
	Himanshu Madhani <[email protected]>
Subject: Re: [PATCH v7 4/9] block: Add core atomic write support
Date: Mon, 3 Jun 2024 14:31:04 +0200	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 6/3/24 13:38, John Garry wrote:
> On 03/06/2024 10:26, Hannes Reinecke wrote:
>>>
>>> +static bool rq_straddles_atomic_write_boundary(struct request *rq,
>>> +                    unsigned int front_adjust,
>>> +                    unsigned int back_adjust)
>>> +{
>>> +    unsigned int boundary = queue_atomic_write_boundary_bytes(rq->q);
>>> +    u64 mask, start_rq_pos, end_rq_pos;
>>> +
>>> +    if (!boundary)
>>> +        return false;
>>> +
>>> +    start_rq_pos = blk_rq_pos(rq) << SECTOR_SHIFT;
>>> +    end_rq_pos = start_rq_pos + blk_rq_bytes(rq) - 1;
>>> +
>>> +    start_rq_pos -= front_adjust;
>>> +    end_rq_pos += back_adjust;
>>> +
>>> +    mask = ~(boundary - 1);
>>> +
>>> +    /* Top bits are different, so crossed a boundary */
>>> +    if ((start_rq_pos & mask) != (end_rq_pos & mask))
>>> +        return true;
>>> +
>>> +    return false;
>>> +}
>>
>> But isn't that precisely what 'chunk_sectors' is doing?
>> IE ensuring that requests never cross that boundary?
>>
> 
>> Q1: Shouldn't we rather use/modify/adapt chunk_sectors for this thing?
> 
> So you are saying that we can re-use blk_chunk_sectors_left() to 
> determine whether merging a bio/req would cross the boundary, right?
> 
> It seems ok in principle - we would just need to ensure that it is 
> watertight.
> 

We currently use chunk_sectors for quite some different things, most 
notably zones boundaries, NIOIB, raid stripes etc.
So I don't have an issue adding another use-case for it.

>> Q2: If we don't, shouldn't we align the atomic write boundary to the 
>> chunk_sectors setting to ensure both match up?
> 
> Yeah, right. But we can only handle what HW tells.
> 
> The atomic write boundary is only relevant to NVMe. NVMe NOIOB - which 
> we use to set chunk_sectors - is an IO optimization hint, AFAIK. However 
> the atomic write boundary is a hard limit. So if NOIOB is not aligned 
> with the atomic write boundary - which seems unlikely - then the atomic 
> write boundary takes priority.
> 
Which is what I said; we need to check. And I would treat a NOIOB value 
not aligned to the atomic write boundary as an error.

But the real issue here is that the atomic write boundary only matters
for requests, and not for the entire queue.
So using chunk_sectors is out of question as this would affect all 
requests, and my comment was actually wrong.
I'll retract it.

Cheers,

Hannes


  reply	other threads:[~2024-06-03 12:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02 14:09 [PATCH v7 0/9] block atomic writes John Garry
2024-06-02 14:09 ` [PATCH v7 1/9] block: Pass blk_queue_get_max_sectors() a request pointer John Garry
2024-06-02 14:09 ` [PATCH v7 2/9] fs: Initial atomic write support John Garry
2024-06-05  8:30   ` Christoph Hellwig
2024-06-05 10:48     ` John Garry
2024-06-06  5:41       ` Christoph Hellwig
2024-06-06  6:38         ` John Garry
2024-06-02 14:09 ` [PATCH v7 3/9] fs: Add initial atomic write support info to statx John Garry
2024-06-02 14:09 ` [PATCH v7 4/9] block: Add core atomic write support John Garry
2024-06-03  9:26   ` Hannes Reinecke
2024-06-03 11:38     ` John Garry
2024-06-03 12:31       ` Hannes Reinecke [this message]
2024-06-03 13:29         ` John Garry
2024-06-05  8:32           ` Christoph Hellwig
2024-06-05 11:21             ` John Garry
2024-06-06  5:44               ` Christoph Hellwig
2024-06-05  8:31         ` Christoph Hellwig
2024-06-02 14:09 ` [PATCH v7 5/9] block: Add atomic write support for statx John Garry
2024-06-02 14:09 ` [PATCH v7 6/9] block: Add fops atomic write support John Garry
2024-06-02 14:09 ` [PATCH v7 7/9] scsi: sd: Atomic " John Garry
2024-06-02 14:09 ` [PATCH v7 8/9] scsi: scsi_debug: " John Garry
2024-06-02 14:09 ` [PATCH v7 9/9] nvme: " John Garry
2024-06-07  6:16 ` [PATCH v7 0/9] block atomic writes John Garry

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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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