Messages in this thread |  | | Date | Thu, 17 Oct 1996 07:51:13 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: Linux-2.1.4 |
| |
On Wed, 16 Oct 1996, Theodore Y. Ts'o wrote: > > Trust me, the new code still _is_ snappier than just about everything. In > fact, I can more-or-less guarantee that it cannot be done faster than we do > it now (modulus some localized optimizations). But the new code is also > _different_ than the old code, and doing loops a byte at a time > degraded from just "stupid" (in 2.0.x) to outright "insane" (in 2.1.x). > > Well, the tty layer code does this all over, mostly to avoid the number > of copies that it needed to make --- remember, for the tty code a "byte" > is the natural size that you generally want to work with. (For an i386 > running at 40MHz, that is the fastest way to do things; I can understand > that on an Alpha w/o byte instructions, it might be much more painful.) > > So will it be faster now to copy everything from userspace into a kernel > "bounce buffer" first, instead of fetching things from user space one > byte at a time? That seems counter-intuitive, since traditionally the > way you get speedups is to *reduce* the number of memory copies while > going through a network or tty layer....
Don't worry. Byte sized accesses aren't really _that_ expensive. In places where byte-sized copies are natural (and I'd agree that the tty layer certainly counts as one) just continue to use them. After all, the tty layer tends to do some operations on those bytes, so it's actually _logical_ to get them as bytes rather than in larger blocks.
The places I reacted against were not places like the tty layer, but places that really don't do "byte" operations in the first place. The ELF loader really does a "memset()", which is definitely not a byte-at-a-time operation except for the most stupid implementation. Similarly, most fast "strncpy()" implementations tend to do word copies and do various tricks to find the zero in the word. And I'm not talking about the kernel implementation here: I'm talking about optimized _libc_ implementations.
Note that the overhead of "get_user()" is something like 10 assembler instructions. It's NOT a costly operation in itself, but the instructions do add up if you keep on doing them ;)
In short: if you actually do some _operation_ on the byte or word you're fetching, the 10 instructions to fetch it are generally not the problem, and doing double-buffering would only complicate the code more (certainly more than 10 instructions). It's only if you're doing things like area copies or clears that byte-wise operations are really silly, because there is obviously a much better way to do them.
(And I wouldn't worry about an alpha keeping up with the tty layer. Trust me, most alpha's have no problem at all with keeping up ;)
Linus
|  |