Readfile System Call Revised For Efficiently Reading Small Files

[phoronix]

Phoronix: Readfile System Call Revised For Efficiently Reading Small Files

Brought up back in 2020 was the readfile system call for efficiently reading small files with the intention of it being simple for reading small files such as those via sysfs, procfs, and similar file-systems. The readfile patches were re-based yesterday against the current Linux 6.0 state, leaving hope that the new system call might finally be sent in for the next kernel cycle...

https://www.phoronix.com/news/Linux-Readfile-Syscall-2022

[archkde]

I don't really get the use-case here. What kind of application hammers sysfs with reads during its regular operation, but can't queue them in userspace and then execute them in batch using io_uring for even greater speedup?

[AlanTuring69]

I don't understand why such non-Unix syscalls are even being considered by kernel "maintainers"? Has Micro$oft really infiltrated my kernel?

p.s. if you even considered what I said to be true then re-evaluate yourself. It's obvious that this is to help some niche use-cases that just need to readfile simply. IO_uring is overkill for these use-cases and readile already exists so no reason not to make it more efficient

[F.Ultra]

I don't really get the use-case here. What kind of application hammers sysfs with reads during its regular operation, but can't queue them in userspace and then execute them in batch using io_uring for even greater speedup?

One use case was linked in TFA, the last time this was brought up it was claimed that io_ring is not designed for this open->read->close type of sequence of operations, io_ring is also vastly more complex to setup than a simple call to readfile(), but most importantly Greg is the dev/inventor for both readfile() and io_uring so he obviously have good reasons for introducing a new syscall over his io_uring pet project.

[ayumu]

Thousands of syscalls (now one more!) and millions of LoCs. Of course, all running in supervisor mode. What could possibly go wrong.

[jrdoane]

What kind of speedup are we talking here? I'd assume that the claim that it's efficient for small files should come with proof. Are we really wasting that many cycles otherwise?

[markg85]

What kind of speedup are we talking here? I'd assume that the claim that it's efficient for small files should come with proof. Are we really wasting that many cycles otherwise?

Look back in previous posts on this or the mailing lists. There definitely are performance numbers and IIRC they were double digit gains for sure.
But... the way you state it makes no sense in reality. Just having this optimization isn't suddenly going to make an application x times faster or more efficient. It would make a very small subset of an application (reading small files) a lot more efficient. But the application as a whole probably won't be much more efficient from a user point of view.

So which apps do benefit? Think of something like top or the gui system monitoring tools. They could become a very fair bot more efficient, might use substantially less cpu cycles themselves! But to you, as a user, it'd still work the same.

[F.Ultra]

Thousands of syscalls (now one more!) and millions of LoCs. Of course, all running in supervisor mode. What could possibly go wrong.

There are 341 in total, not thousands, but pray tell what could go wrong from having 342 syscalls. The millions of LoCs are drivers, so of those only a small subset are running at a system at a time.

[oiaohm]

I don't really get the use-case here. What kind of application hammers sysfs with reads during its regular operation, but can't queue them in userspace and then execute them in batch using io_uring for even greater speedup?

https://lwn.net/Articles/813827/

readfile and io_uring are not two different things here. readfile syscall makes it one operation to open read and close a small file. Yes this take 3 operations and make its 1. Readfile can also be implement on io_uring once the readfile syscall works and is in the kernel. Yes same thing that instead of 3 io_uring operations you reduce to 1 one readfile is confirmed as a working syscall..

Yes each of those individual operations open, read and close do result in having to acquire locks. The same locks. Open has you acquire and release locks, read has you acquire and release locks and close has you acquire and release locks.

[jacob]

I don't understand why such non-Unix syscalls are even being considered by kernel "maintainers"? Has Micro$oft really infiltrated my kernel?

Your kernel is Linux, not Unix. Who are you to mandate that it must slavishly imitate Unix for ever and ever?