Messages in this thread | | | Date | Tue, 15 Dec 1998 19:40:28 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: PATCH: Raw device IO for 2.1.131 |
| |
On Sat, 12 Dec 1998, David S. Miller wrote: > > Linus, if what you want to say is that it's "ok" to have the data go > in and out of the CPU cache for every I/O, and that twiddling block > and inode allocation bits in the filesystem code is "ok" for every > I/O, then you need to have your head seriously examined.
Did you actually bother to read my mail?
There are two cases: - real work. The CPU actually generates the data rather than copying it around.
For this case you do mmap() etc, and maybe you have a clever "write()" routine that knows to instead of allocating a new page and copying the data into the page cache it just steals the page if it can. But in NO case is this anything that has anything at all to do with raw devices, because the most common case by far is to just spew the data over the network or into a file (NOT a partition).
- copying data. We do sendfile() or similar. Zero-copy, and without any of the "lock down user pages" crap.
If you want memory speeds, you do NOT want to have the TLB and possibly virtual caches and other crap in your way. In short, you do NOT want to have the user mapping stuff in your way at all.
Basically, I'm arguing against two things: - raw devices as a performance issue. They aren't. If raw devices are faster than a file, then you have your priorities wrong, and you need to screw on your head the right way. - messing with user mappings. It's way tyoo seductive, and it screws you way too much. Only as a last way out will you do that.
I'm not arguing against zero-copy per se. I'm arguing against people who think memory management tricks are a good idea. They generally aren't, look at where Mach is.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |