On 10/2/23 04:53, Niklas Cassel wrote:
On Mon, Oct 02, 2023 at 01:37:59PM +0200, Niklas Cassel wrote:
I don't know which user facing API Martin's I/O hinting series is intending
to use.
However, while discussing this series at ALPSS, we did ask ourselves why this
series is not reusing the already existing block layer API for providing I/O
hints:
https://github.com/torvalds/linux/blob/v6.6-rc4/include/uapi/linux/ioprio.h#L83-L103
We can have 1023 possible I/O hints, and so far we are only using 7, which
means that there are 1016 possible hints left.
This also enables you to define more than the 4 previous temperature hints
(extreme, long, medium, short), if so desired.
There is also support in fio for these I/O hints:
https://github.com/axboe/fio/blob/master/HOWTO.rst?plain=1#L2294-L2302
When this new I/O hint API has added, there was no other I/O hint API
in the kernel (since the old fcntl() F_GET_FILE_RW_HINT / F_SET_FILE_RW_HINT
API had already been removed when this new API was added).
So there should probably be a good argument why we would want to introduce
yet another API for providing I/O hints, instead of extending the I/O hint
API that we already have in the kernel right now.
(Especially since it seems fairly easy to modify your patches to reuse the
existing API.)
One argument might be that the current I/O hints API does not allow hints to
be stacked. So one would not e.g. be able to combine a command duration limit
with a temperature hint...
Hi Niklas,
Is your feedback about the user space API only or also about the
mechanism that is used internally in the kernel?
Restoring the ability to pass data temperature information from a
filesystem to a block device is much more important to me than
restoring the ability to pass data temperature information from user
space to a filesystem. Would it be sufficient to address your concern
if patch 2/13 would be dropped from this series?
Thanks,
Bart.
