On Wed, Mar 14, 2018 at 12:31:22PM +0100, Miklos Szeredi wrote: > On Wed, Mar 14, 2018 at 12:17 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > >> And we already have an interface for this: splice(2). What am I > >> missing? What's the killer argument in favor of the above messing > >> with tlb caches etc, instead of just letting the kernel do the dirty > >> work. > > > > Great question. You're completely right that the question is how to tell > > the kernel what to copy. The problem is that splice() can only write to > > the first page of a pipe. So you need one pipe per outstanding request, > > which can easily turn into thousands of file descriptors. If we enhanced > > splice() so it could write to any page in a pipe, then I think splice() > > would be the perfect interface. > > Don't know your usecase, but afaict zufs will have one queue per cpu. > Having one pipe/cpu doesn't sound too bad. Erm ... there's nothing wrong with having one pipe per CPU. But pipes being non-seekable means that ZUFS can only handle synchronous I/Os. If you want to have a network backend, then you'd only be able to have one outstanding network request per pipe, which is really going to suck for bandwidth. > But yeah, there's plenty of room for improvement in the splice > interface. Just needs a killer app like this :) I'm happy to start investigating making pipes random-access ...
