I ran 2.2.8 on a dual-PII Xeon-450. My standard perf test is to recreate
25 or so indexes on a 150MB table. This only exercises one CPU, and all
data fits in memory. On the non-I/O-bound runs, 2.2.8 was about 9% faster
than 2.2.7! Very nice.

My question is about the new bdflush behavior. When I run a heavy load of
inserts on the db, I get very bursty I/O. I realize this is because of
update running sync every 30 seconds, but it seems to me that the internal
bdflush behavior is perhaps flushing too conservatively? I hardly get any
block writes at all, and then it spikes every 30s. In this particular
example, vmstat shows 250 blocks/s about every 5 seconds, then I get a
spike of 3000 blocks/s for about 10 seconds.

This is obviously nonoptimal, as it means during heavy writing loads, the
system slows dramatically for periods of time. I'm also concerned about
data integrity and whether turning off update would potentially cause
dirty buffers to hang around for large amounts of time (like 10 minutes
maybe).

Any thoughts? Perhaps the flush algorithm should be revisited to more
closely match the default behavior of update? I'm wondering if maybe I
should run update as 'update -S -s 2' to cut back on the spikes.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/