Buffers vs. tty throughput

[Geoff Steckel - Sun BOS Hardware CONTRACTOR]

 johnl at iecc.cambridge.ma.us (John R. Levine) writes:
 
 >I have an internal Telebit with a 16550 UART, and uucp connections generally
 >run between 800 and 1100 cps, depending on who's on the other end......
 >I built a new kernel with 4000 rather than 2000 buffers.  It works OK, except
 >for one thing -- uucp throughput stinks.  It was down around 400 cps.....
 >
 >What is going on?  The most likely thing I can think of is that somewhere in
 >the buffer management code there is an N^2 algorithm that runs with
 >interrupts masked, and with 4000 buffers it takes so long that even with a
 >16550 I lose interrupts.  I note that in the mtune file, 2000 is the maximum

I don't know if this has survived into missed'em V.3, BUT...  There were at
least two places where truly silly things happen w.r.t. the buffer cache in
V7 & friends.

1) disksort - inserting a buffer into a driver's to-be-written queue used a
quadratic (or worse) algorithm at spl6().
2) sync() - when a sync occurs, the entire cache was scanned, and one by one,
each modified block was placed in the driver's write queue, using disksort....
(can you say n^3!).
3) every read() and write() call on the serial device caused the inode for
the serial line to be updated with the current time (access/modification),
which searches the buffer pool (at spl6()) - hundreds of times a second...

I think there were more, but I forget lots.

Losing even one character can cause a truly awful degradation of UUCP transmission
rate.

I hope this helps someone.
	geoff steckel (gwes at wjh12.harvard.EDU)
			(...!husc6!wjh12!omnivore!gws)
Disclaimer: I am not affiliated with Sun Microsystems, despite the From: line.
This posting is entirely the author's responsibility.