On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote: > > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > > > You should probably take a look at io_uring. That has the level of > > > complexity of this proposal and supports open/read/close along with many > > > other opcodes. > > > > Then glibc can implement readfile using io_uring and there is no need > > for a new single-file readfile syscall. > > It could, sure. But there's also a value in having a simple interface > to accomplish a simple task. Your proposed API added a very complex > interface to satisfy needs that clearly aren't part of the problem space > that Greg is looking to address. I believe that we should look at the single-file readfile syscall from a performance viewpoint. If an application is expecting to read a couple of small/medium-size files per second, then neither readfile nor readfiles makes sense in terms of improving performance. The benefits start to show up only in case an application is expecting to read at least a hundred of files per second. The "per second" part is important, it cannot be left out. Because readfile only improves performance for many-file reads, the syscall that applications performing many-file reads actually want is the multi-file version, not the single-file version. I am not sure I understand why you think that a pointer to an array of readfile_t structures is very complex. If it was very complex then it would be a deep tree or a large graph.
