Messages in this thread |  | | Date | Fri, 19 Jan 2001 01:18:01 +0100 (MET) | From | Roman Zippel <> | Subject | Re: Is sendfile all that sexy? |
| |
Hi,
On Thu, 18 Jan 2001, Linus Torvalds wrote:
> It's too damn device-dependent, and it's not worth it. There's no way to > make it general with any current hardware, and there probably isn't going > to be for at least another decade or so. And because it's expensive and > slow to do even on a hardware level, it probably won't be done even then. > > [...] > > An important point in interface design is to know when you don't know > enough. We do not have the internal interfaces for doing anything like > this, and I seriously doubt they'll be around soon.
I agree, it's device dependent, but such hardware exists. It needs of course its own memory, but then you can see it as a NUMA architecture and we already have the support for this. Create a new memory zone for the device memory and keep the pages reserved. Now you can use it almost like other memory, e.g. reading from/writing to it using address_space_ops.
An application, where I'd like to use it, is audio recording/playback (24bit, 96kHz on 144 channels). Although it's possible to copy that amount of data around, but then you can't do much beside this. All the data is most of the time only needed on the soundcard, so why should I copy it first to the main memory?
Right now I'm stuck to accessing a scsi device directly, but I would love to use the generic file/address_space interface for that, so you can directly stream to/from any filesystem. The only problem is that the fs interface is still to slow.
That's btw the reason I suggested to split the get_block function. If you record into a file, you first just want to allocate any block from the fs for that file. A bit later when you start the write, you need a real block. And again a bit later you can still update the inode. These three stages have completely different locking requirements (except the page lock) and you can use the same mechanism for delayed writes.
Anyway, now with the zerocopy network patches, there are basically already all the needed interfaces and you don't have to wait for 10 years, so I think you need to polish your crystal ball. :-)
bye, Roman
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |