On 9/12/24 10:26, Christoph Hellwig wrote:
On Tue, Sep 10, 2024 at 09:10:34PM +0100, Pavel Begunkov wrote:
If we expect any error handling from the user space at all (we do),
it'll and have to be asynchronous, it's async commands and io_uring.
Asking the user to reissue a command in some form is normal.
The point is that pretty much all other errors are fatal, while this
is a not supported for which we have a guaranteed to work kernel
Yes, and there will be an error indicating that it's not
supported, just like it'll return an error this io_uring
commands are not supported by a given kernel.
fallback. Kicking it off reuires a bit of work, but I'd rather have
that in one place rather than applications that work on some hardware
and not others.
There is nothing new in features that might be unsupported,
because of hardware or otherwise, it's giving control to the
userspace.
That's a shame, I agree, which is why I call it "presumably" faster,
but that actually gives more reasons why you might want this cmd
separately from write zeroes, considering the user might know
its hardware and the kernel doesn't try to choose which approach
faster.
But the kernel is the right place to make that decision, even if we
aren't very smart about it right now. Fanning that out to every
single applications is a bad idea.
Apart that it will never happen
Users who know more about hw and e.g. prefer writes with 0 page as
per above. Users with lots of devices who care about pcie / memory
bandwidth, there is enough of those, they might want to do
something different like adjusting algorithms and throttling.
Better/easier testing, though of lesser importance.
Those I made up just now on the spot, but the reporter did
specifically ask about some way to differentiate fallbacks.
Well, an optional nofallback flag would be in line with how we do
that. Do you have the original report to share somewhere?
Following with another flag "please do fallback", at which
point it doesn't make any sense when that can be done in
userspace.
--
Pavel Begunkov
