Andrea Righi wrote:Actually it's a little-known easy problem. The capacity planning community does it all the time, but then describes it in terms that are only interesting (intelligible?) to an enthusiastic amateur mathematician (;-)) One finds the point, called N*, at which the throughput flattens out and and the response time starts to grow without bounds, and calls that level the maximum. In practice, one does an easier variant. One sets a response-time limit and throttles *everyone* proportionally when th disk starts to regularly degrade beyond the limit. Interestingly, because we're slowing the application to prevent slowing the disks, the value we pick needn't be terribly precise. It also doesn't require any pre- knowledge about the disks. Send me a note if you want to discuss this in more detail. --dave -- David Collier-Brown | Always do right. This will gratify Sun Microsystems, Toronto | some people and astonish the rest davecb@sun.com | -- Mark Twain cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191# --
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Linus Torvalds | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | 2.6.25-mm1 |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Natalie Protasevich | [BUG] New Kernel Bugs |
