On Wed, Mar 14, 2018 at 12:45 PM, Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > 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. I guess ZUFS is mostly about fast synchronous access (please correct me if I'm wrong). Not sure that model fits network filesystems, where performance of caching will dominate real life performance. Thanks, Miklos
