Re: [PATCH 01/21] block: Add atomic write operations to request_queue limits

On 10/11/2023 06:23, Christoph Hellwig wrote:

On Thu, Nov 09, 2023 at 05:01:10PM +0000, John Garry wrote:

quoted

Generally they come from the same device property. Then since
atomic_write_unit_max_bytes must be a power-of-2 (and
atomic_write_max_bytes may not be), they may be different.

How much do we care about supporting the additional slack over the
power of two version?

I'm not sure yet. It depends on any merging support and splitting 
safeguards introduced.

quoted

In addition,
atomic_write_unit_max_bytes is required to be limited by whatever is
guaranteed to be able to fit in a bio.

The limit what fits into a bio is UINT_MAX, not sure that matters 😄

I am talking about what we guarantee that we can always fit in a bio 
according to request queue limits and bio vector count, e.g. if the 
request queue limits us to 8 segments only, then we can't guarantee to 
fit much in (without splitting) and need to limit atomic_write_unit_max 
accordingly.

quoted

atomic_write_max_bytes is really only relevant for merging writes. Maybe we
should not even expose via sysfs.

Or we need to have a good separate discussion on even supporting any
merges.  Willy chimed in that supporting merges was intentional,
but I'd really like to see numbers justifying it.

So far I have tested on an environment where the datarates are not high 
and any merging benefit was minimal to non-existent. But that is not to 
say it could help elsewhere.

Thanks,
John