Messages in this thread | | | Date | Fri, 21 Apr 2006 09:53:21 +0200 | From | Jens Axboe <> | Subject | Re: Linux 2.6.17-rc2 |
| |
On Fri, Apr 21 2006, Nick Piggin wrote: > Linh Dang wrote: > >Jens Axboe <axboe@suse.de> wrote: > > >>DVD burning probably isn't a good splice fit, since you need to do > >>more than actually just point the device at the data. SG_IO is > >>already zero-copy as it maps the user data into the kernel without > >>copying, so there's very little room for improvement there to begin > >>with. > > > > > >DVD burning on linux is mostly: > > > > mkisofs .... | growisofs .... > > > >Ideally, on mkisofs side, we'd be able to: > > > > - write some data/padding into the pipe > > - splice a HUGE file into the pipe > > - write some data/padding into the pipe > > - splice a HUGE file into the pipe > > ... > > > >On growisofs side, we'd be able to: > > > > - send some commands > > - splice N MBs of data from the pipe to the driver > > - send some commands > > - splice M MBs of data from the pipe to the driver > > ... > > > >What'd be nice is an ioctl to change the size of the pipe between > >mkisofs and growisofs. > > I don't see why the pipe buffers would be a problem though. It isn't > like you've lost any of the pagecache buffering (eg. from readahead) > or the application level buffering.
Yes, hence the reason that a larger pipe / dynamic pipe wasn't even attempted yet. In the tests I did, manually increasing the pipe size yielded no noticable benefits.
Conceptually it might be simpler for the mkisofs side to accept larger in-kernel pipes, but on the performance side I doubt it would matter a lot. The growisofs side sending data to the drive is not limited by the 64k pipe, typically the commands will be smaller than that anyways. So "splice N MBs of data from the pipe to the driver" is a nice dream, but that's not how you talk to the device anyways.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |