Re: a joint letter on low latency and Linux

[Linus Torvalds]

Just to clear up my opinion a bit:
 - I'm definitely not against low latency. I think latency is hugely
   important, mostly more so than throughput (within reason, of course:
   all this is very much a balancing issue).
 - I'm not even against well-defined and well-thought-out "scheduling
   points". They are hackish, but if there is one or two of them to cover
   some specific behaviour then that's ok. Not a big deal.
 - I _am_ against patches whose only purpose in life is to run some
   arbitrary benchmark, and try to make that benchmark look good.

Most of the low-latency patches I've seen have been of the third kind, I'm
afraid.

For example, I would probably accept a patch that adds a simple

	if (current->need_resched) schedule();

to the case of generic_file_write/generic_file_read. Why? Because that
case is a real-world case where it's obvious that with huge caches a
normal user can quite simply cause bad latencies, and this is not an issue
that needs all that much discussion - it's an obvious hack, but is't also
equally obvious why it's there, and what the point of it is. We've had a
few of these before: I think the /dev/null driver already does exactly
this.

In fact, because we should look at the "UP threading code" for 2.5.x
anyway (ie using the spinlocks on UP to generate a fairly well-threaded UP
kernel without any source modifications), the one-liner if-statement
should probably be a #define with a simple-to-grep-for name so that it can
be easily removed. 

Why just "probably"? A few reasons:

 - I suspect that especially if we generate such a macro, people will
   start sprinkling it around at various random places. And I do not want
   such a simple hack to spread out any more than necessary. One or two
   places are fine. So is four. Numerous places in the networking code,
   device drivers and filesystems doing it is _not_. At that point it has
   gone from a very specific and slightly tasteless hack to an ugly
   architecture.

   This could probably be avoided by giving it a clear comment and a
   discouraging name.

 - I do think the "copy_to/from_user()" case is the cleaner one, but I'd
   hate to do the test in-line, and I'd hate to do it all over the place.
   And if we do it in copy_to/from_user(), we don't do it _anywhere_ else:
   again the difference is one between a slightly tasteless hack, and a
   ugly rule of life.

   This is the more complex case, and requires more careful code in
   <asm/uaccess.h>. The "generic" arbitrarily-sized functions should
   probably be moved out-of-line into arch/xxx/lib/uaccess.c, because that
   test is no longer worth doing inline. Together with benchmark runs.

See? "slightly tasteless" and "strictly localized" are ok. Anything more
hackish than that is not.

		Linus