Re: Linux 2.6.17-rc2

[Jens Axboe <axboe@suse.de>]

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/