> Jan Kratochvil wrote:
> > P.S.: When we're at another large memory copying, will someone the write page
> > flipping support so that during CD burn the data will no longer be copied
> > 6 times? Count with me:
> >
> > [disk DMA->kernel buffer]
> > 1. buffer -> userland mkisofs
> > 2. mkisofs -> kernel pipe buffer
> > 3. kernel pipe buffer -> userland buffering tool
> > [>10MB buffer to deal with starvations during compiles]
> > 4. userland buffering tool -> kernel pipe buffer
> > 5. kernel pipe buffer -> userland cdrecord buffer
> > 6. userland cdrecord buffer -> scsi layer buffer
> > [scsi layer->scsi controller DMA]
>
> To get this to work better, you could:
> 1) Use a ring buffer in shared memory instead of pipes for the
> "userland buffering tool".
The buffering tool (my unrealesed "pipebuf") already uses ring buffer in
IPC shared memory shared by 2 processes - each one is always stuck
in read() or write() respectively. But they're reading/writing from/to
pipe which means that each read/write requires 2 copies (to and from
kernel buffer). This can be solved by implementing this IPC shm buffering
directly to mkisofs and cdrecord and avoing the whole pipebuf. But this
requires modification of standard tools and this is not a real solution.
EVERY pipe on system (typically gzip-tar) requires two copying and
rewriting all the tools is a very broken idea. This should be solved
on the kernel side.
> 2) Use the new raw devices for the disk image of the CDROM when they
> become available from Dave Miller.
Yes, it would be a little bit better but it would be nice to cache also
ext2 metadata (not applicable to raw devices) as the CD image is generated
by mkisofs from filesystem structure on the flow. But I agree that
avoiding thrasing of page cache would be a big win.
> 3) Modify the Generic SCSI driver so it can point to a data buffer
> (or a chain of them) in user-land for read/writes instead of
> mixing up commands and data in one non-aligned io block. Not
> sure what the consequences are here if you give the generic
> SCSI driver a memory area that doesn't belong to you ie it
> 'seg faults' in the DMA.
Good idea but let do this someone else, please ;-)
> Then you get:
>
> 1. DMA raw partition -> ring buffer in shared memory.
> 2. DMA ring buffer in shared memory -> SCSI card with CD writer.
Yes but with modification of mkisofs/cdrecord which is not wised.
> This is assuming that data gets copied verbatim from the disk
> to the CDROM.
I thought about on-the-fly image generation but it applies either.
> Of course, the ideal would be to DMA directly from the disk
> to the CD across the PCI bus. Hey they might be on the same
> SCSI controller, then the data never has to leave the
> controller... :-).
:-) Are the current SCSI disks so smart so they are able to be commanded
to intiate connection disk->cdwriter? I don't think so... Especially
various cheap IDE-like disks...
Jan Kratochvil