On Mon, Nov 12, 2007 at 08:12:37PM -0500, Thor Lancelot Simon wrote:
> Really to fix this I think you need to have some idea how many tps your
> disk subsystem can soak up (this will never be perfect but you can get
> a lot closer than we do now just by observing the maximum and perhaps
> leaky-bucketing it) and then you need to enqueue I/O into each of the
> seconds from now until some maximum in the future where if you've enqueued
> I/O that far, you really _do_ start blocking processes.  That is, look at
> each second (or 1/10 second, or even a smaller quantum) as a bucket to be
> filled up with transactions, probably to no more than half the maximum tps
> you've seen in the past, and start filling from now (or some initial delay
> value meant to catch I/O that becomes redundant) into the future.

This is what I'd like to test.  (Sorry, no I can't write the code.)

The algorithm should also quickly adapt to varying tps values - for twa,
tps varies between a few hundred and some 2000.  The busier it gets, the
slower it becomes, it seems.  So, limiting tps to something below 100%
of the maximum _might_ make things faster.  Might. :)

  -jm