Date:	Sat, 12 Dec 1998 14:09:48 -0800 (PST)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	Larry McVoy <lm@bitmover.com>
Subject: Re: PATCH: Raw device IO for 2.1.131



On Sat, 12 Dec 1998, Larry McVoy wrote:
> 
> So, Linus, I know you haven't been thrilled about "raw I/O" and that you
> have some very valid reasons for not wanting it in the kernel.  Does the 
> patch for raw device I/O come anywhere near being good enough that you 
> are OK with it?  If not, can you suggest what it would need to look like?

I have almost no reason to be thrilled about the patches. Two reasons:
 - raw device access is not interesting. It's not performance-critical,
   and I think it's stupid to think that it is. In particular, I will
   completely ignore anything that does any silly page locking tricks to
   send data from user space. Not worth optimizing.
 - sendfile() is a completely different issue. Being able to send or
   receive directly into the page cache makes sense, and allows (with
   mmap) to have user level access to the data too - without any locking
   issues or any ugliness at all. All real IO is done in kernel space, the
   user just gets a window into it.. Very simple.

Quite frankly, nobody has EVER given me a reason that makes any kind of
sense at all for supporting raw devices in any other way than we already
do. Nobody sane uses a disk without a filesystem, and the insane people
that do I feel we can and should ignore. Insanity has a way of dying off
over time, when Darvin starts to look into it. 

I _would_ support the notion of being able to say "push this out now" and
"don't leave this lying around in your cache" kind of raw device
semantics. However, anybody that brings in performance into the picture I
will simply ignore because I don't think raw disk access has anything at
all to do with performance.

I think a lot of people are deluding themselves by running benchmarks on a
raw device, without ever asking themselves whether it makes any sense at
all what-so-ever. In my mind, if you can't do it to a file, it's not worth
doing at all.

I've also become almost completely uninterested in zero-copy schemes. They
make for great benchmarks, but have little relevance to anything else. You
have two cases:
 - sendfile() like copying things around. We want to do zero-copy here,
   but it's easy because everything is already in kernel space.
 - real work. If zero-copy makes a real difference, you'd better buy a new
   computer, because your memory subsystem is too slow. Either you're IO
   bound or you aren't, and if you're IO bound and your memory is slower
   than your IO then it's not something the OS should do all that much
   about. And if you aren't IO-bound, then the whole discussion is moot.

Yes, there are still machines with bad memory subsystems compared to their
IO systems, but Linus "the Oracle" Torvalds is convinced that they are a
short-lived oddity in the industry and shouldn't be designed for, the same
way you shouldn't design for direct-mapped caches or for machines without
paging hardware.

So I want to be able to do things like frame capture (into a _file_, not a
partition) etc, and there I think something like sendfile() is the answer
(well, "copyfd()", whatever). And there I also think that we currently
would do fairly badly on the write-out part due to the known problems with
buffer cache behaviour under certain circumstances. But basically I still
see absolutely no reason for supporting raw devices per se. 

		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/