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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 Aug 2008 12:35:23 -0400
From:	David Collier-Brown <davecb@....com>
To:	Naveen Gupta <ngupta@...gle.com>
Cc:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Dave Hansen <dave@...ux.vnet.ibm.com>,
	Ryo Tsuruta <ryov@...inux.co.jp>,
	yoshikawa.takuya@....ntt.co.jp, taka@...inux.co.jp,
	uchida@...jp.nec.com, linux-kernel@...r.kernel.org,
	dm-devel@...hat.com, containers@...ts.linux-foundation.org,
	virtualization@...ts.linux-foundation.org,
	xen-devel@...ts.xensource.com, agk@...rceware.org,
	Andrea Righi <righi.andrea@...il.com>
Subject: Re: RFC: I/O bandwidth controller (was Re: Too many I/O controller
 patches)

A minor sidebar:
2008/8/7 Fernando Luis Vázquez Cao <fernando@....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@....com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#

Download attachment "usual.gif" of type "image/gif" (7997 bytes)