Is there a reason MAXPHYS (currently = 64 * 1024) should not be raised,
at least on i386/amd64?

It appears that 64K transfers on a 120 MB/sec disk incurs about
1800 interrupts/second. The limit seems low for a modern system
and the interrupt rate is high.

Does anyone see bad consequences from raising MAXPHYS to 256K
and reducing the interrupt rate? Yes, it would mean more pages
locked down for larger transfers.

I ask this because on almost identical motherboards and CPUs
and exactly identical drives, Linux is faster (approx. 143MB/sec vs. 114MB/sec).
Linux is using a *lot* more CPU (approx 20% system & interrupt time)
OpenBSD is almost idle. It is taking about 1000 interrupts per second
that appear to be disk-related.

My guess from the Linux vmstat numbers is that it is reading
128K or more at a time - approx 1000 transfers/sec and approx 143 MB/sec.
It may be queueing readahead requests which would overlap interrupt
service with hardware I/O - I don't know.

uname -a
OpenBSD lib.oat.com 4.9 GENERIC.MP#819 amd64

dd if=/dev/rsd1c bs=2m of=/dev/null count=10000
10000+0 records in
10000+0 records out
20971520000 bytes transferred in 184.068 secs (113932934 bytes/sec)

uname -a
Linux ping 2.6.32-34-generic-pae #77-Ubuntu SMP Tue Sep 13 21:16:18 UTC 2011 i686 GNU/Linux

dd if=/dev/sdb of=/dev/null bs=2M count=10000
10000+0 records in
10000+0 records out
20971520000 bytes (21 GB) copied, 147.096 s, 143 MB/s

It's easy to make this change. Finding any bad consequences
would be harder, and I'd like any available wisdom first.
I have a reason to push disks as fast as hardware
allows and want to reduce software-induced bottlenecks
as much as possible.

thanks!
  Geoff Steckel

Reply via email to