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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/11/2023 06:23, Christoph Hellwig wrote:
On Thu, Nov 09, 2023 at 05:01:10PM +0000, John Garry wrote:
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.


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.


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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux