🚀 go-pugleaf

In article <1992Jul17.103656.22219@jarvis.csri.toronto.edu>
	okrieg@eecg.toronto.edu (Orran Y. Krieger) writes:

>For this sort of experiment the cost of a page fault relative to
>the time to copy a page of data (and do a system call..)
>determines which type of operation is faster. From the above
>numbers we can see that on the SunOS 4.1.1 the cost of a read
>page fault is about 530 usec, and 176 usec on the IRIX system.

As the implementation of read() on SunOS 4.1.1 is based on
mmap() and file system performance of SunOS 4.0 is just
brain dead, your measurement on SunOS has almost meaningless
as to whether we should avoid bcopy() or not.

See a paper titled "Why Aren't Operating Systems Getting Faster As
Fast as Hardware?" by John K. Ousterhout in the proceedings of
the Summer 1990 USENIX Conference on how brain dead SunOS 4.0 is.

I haven't actually used IRIX, but, judging from the fact that
IRIX has mmap() for files, it might also be implemented badly.
It is not easy to obtain I/O performance, if I/O traffic is mixed
with paging traffic.

So, if some older version of IRIX does not have mmap() for files,
I recommend you to measure the read() performance of that version.

>  0. it is fair to compare a read of an entire page to a
>     touch of a mapped page, since these correspond to the system cost
>     to get a page of data into the application address space. 

It is not, because, with read() case, data is copied to cache
with high probability.

>  1. these performance numbers were measured on very different
>     hardware platforms (the SunOS 4.0.3 system is a Sun 4/280S,
>     the SunOS 4.1.1 system is a Sun 4/40 and the IRIX system is
>     a SGI Iris 4D/240S) and therefore only allow a comparison
>     between different experiments on the same system. 

Measuring I/O performance on SunOS 4.* and say something on
machine (or OS) dependent I/O performance is MEANINGLESS.

That some I/O performance on SunOS 4.* is bad only means
that that I/O performance on SunOS 4.* is bad.

>However, this ignores a couple of other factors I consider pretty
>important, namely:
>
>  1. If you copy lots of data then you are stressing your memory
>    system, the bottleneck on most modern systems. This is
>    especially the case with a shared memory multiprocessor,

If memory system chokes on I/O traffic, the bus chokes on computation
traffic of slightest load. This is especially true for a shred memory
multiprocessor.

As the memory system is the bottleneck on most systems, it
is designed to have high throughput, which solves half of
the problem. The other half of the problem is turn around time or
memory access time, which has nothing to do with I/O performance.

>    or if
>    you have a large disk array concurrently doing DMA into your
>    system. In [3] they found that the performance of the Raids
>    disk array for large data transfers was limited by the memory
>    bandwidth used for copying data with read operations.

In [3], the reported RAID performance is 2.3MB/sec. With eight
disks, it could be 7MB/sec, if not limited by bus speed. But,
the announced bus speed of SS10 is 100MB/sec. So, bus speed
can not be a limiting factor.

You design a fast I/O system because the processor can process that
fast I/O stream. That is, unless you are just copying files, the
processor MUST process data in some way using the processor bus. So,
proccessor bus must be several times (at least) faster than I/O rate.

						Masataka Ohta