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
