greg (04/19/83)
I just did some (very) rough calculations on cpu time consumed by
the kernel copyin/copyout routines and I found that to copy a 1k buffer
from kernel space to user space takes between 2425 and 3475 microseconds
(depending on ratio of cache hits/non cache hits and such), or about
5.5 microseconds per word. This, to me, seems VERY slow, considering that
our RM05 can (on a good day) transfer 1 word every 1.65 microseconds and
even our RL02's cook along at 1 word every 4 microseconds. To add insult
to injury, if a particular block is not in memory, you have to add the
drive transfer time to the copy time, so for a non-cached buffer the
transfer alone takes between 7 and 9 microseconds per word.
Is seek latency a bad enough problem to justify this? Is there any
way to cut down on kernel<->user copy time? Perhaps on small cpu-bound
systems all I/O should be raw?
Oh, by the way, the statistics are all taken from our PDP-11/44.
Comments/opinions/flames ("What, all I/O RAW?!") are invited.
Greg Travis
decvax!pur-ee!isrnix!greg
p.s. The copy routines we use are modified so that loop control overhead is
minimal.
p.p.s. I've considered using a kernel segmentation register to map into
the users buffer area and using 'bcopy' to do the copy, but this
seems more trouble than it's worth.guy (04/21/83)
Another reason to provide a O_NOCACHE bin on open; you could bypass the
caching overhead. If you were running a big DBMS or a FMS (ISAM, VSAM, etc.),
you'd have your own big buffer pool anyway, so the system buffer pool
might not buy you all that much (see the Stonebraker paper mentioned in an
earlier article); UNIX's caching and read-ahead mechanism won't match what
yours is (Stonebraker mentions a case where INGRES reads a block and KNOWS
what block it is going to want next; unfortunately, UNIX may the next
sequential block from the file instead, or just not read anything ahead);
and your caching will disrupt programs which can make use of the cache.
(It has been mentioned several times that an "exec" rips through the cache
and disrupts it quite a bit, as a lot of the blocks read in will never be
used again.)
BTW, the System III kernel buffers aren't mapped into kernel address space
(except for a few used for things like arg lists, super-blocks, etc.), and
they have a routine which will map the buffer and the source/destination
and use a fast copy loop. Anybody out there have any comparative figures
on, say, PDP-11 V7 buffer copy overhead vs. PDP-11 S3 buffer copy overhead?
If you're reading one character at a time, the fancy copy routine will lose,
of course; on the other hand, if you're reading one character at a time
ANYTHING will lose.
Guy Harris
RLG Corporation
{seismo,mcnc,we13}!rlgvax!guy