>Thank you for clear feedbacks.  I have to recheck why my case had
>hideous throughput. (busy network, sluggissh NFS server)

Either sounds plausible.  I'm not aware of the ioctl asic serializing
scsi and lance access at more than the 16-byte chunks in which the
LANCE sends packet data out its pins, or possibly individual DMA
transactions from the SCSI-bus, so I dont think that's a factor.


I/O benchmarks to the NFS server will show NFS as a bottleneck but
wont' easily tell you whether the problem is the NFS server or the
network itself.  I'd use ttcp or netperf or some such to see if the
network is busy. But if the net is really busy, you should be logging
transmit timeouts.

Last year, I saw a 2x speedup by going from source on a slow (Linux,
in my case) NFS server and objects on a slow local disk, to having
both on a fast local disk.  That would be the simplest, quickest fix.


>By the way, I'm occationally experiencing process lockup symptoms with
>parallel kernel make.  GCCs just stop with flag D and there is no way
>to kill them.  I tracked down the symptoms were related with directory
>lookups, specifically around /usr/src/sys, which are accessed heavily
>and concurrently during parallel kernel make.  Simon, have you ever
>experienced such, or never?

I dunno about Simon, but from compiles on a -current kernel dating
back to March, I would ahve said "never".  Is this also on NFS? it
does sound suspiciously like some NFS problems fvdl mentioned earlier
this year...