RFC: I/O bandwidth controller (was Re: Too many I/O controller patches)

[David Collier-Brown]

A minor sidebar:
2008/8/7 Fernando Luis Vázquez Cao <fernando at oss.ntt.co.jp> wrote"
>>On the one hand, we have the problem of feeding physical devices with IO
>>requests in such a way that we squeeze the maximum performance out of
>>them. Of course in some cases we may want to prioritize responsiveness
>>over throughput. In either case ...

  Maximum performance for non-batch processes is reached soon after
the point at which latency starts to degrade badly, so be very
careful when you're trying for max throughput on anything
that has a queue (e.g., CPUs, disks, etc).

  My usual example is a device that takes 10 milliseconds from
request to end of response, shown in the gif below.

  At load = 10, theoretical throughput should be at 100%. In
fact, it's around 82%, because some queuing is already happening.
Sitting in queue cuts performance, so the response time is already
up to 0.030 seconds (30 milliseconds).  

Trying for 95% of max throughput requires a load of 14, with 
a truly horrid response time of 0.050 seconds (50 milliseconds).

Therefor: we're trying to deliver good response times as a *first*
priority, without throttling the device so it can't deliver
the majority of it's throughput, not the other way around.

By the way, this is the kind of calculation that leads people
to the rule of thumb of using 80% of max throughput as a good 
target.  


--dave

-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb at sun.com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usual.gif
Type: image/gif
Size: 7997 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/containers/attachments/20080811/6c7c3571/attachment-0001.gif