Hello,
I have a few questions on IO limiters.
1. When io_tokens gets negative, is the only way to replenish the stock is to disable io-consuming tasks, and wait for the stock to refill at the token refill_rate?
2. Is there a way to have a quicker token_refill? http://www.theshore.net/~caker/uml/patc ... ter.README
suggests that some configuration is available but I am not sure this is available to linode customers. To some extent, that would defy the purpose of the IO limiter.
3. I read that bigger linodes to not have high token_max or quicker token_refill because "is only there as an "emergency brake" for runaway Linodes"; Can you confirm this is still the case? Intuitively, I would have sais that the bigger the more tokens.
4. Does a linode with more RAM help avoid emptying that reserve of tokens?
Thanks!

Yes. Once you're out, you need to use less IO.
No. Linode sets the refill rate.
As far as I know, everyone gets the same refill rate. A standard web/email/dns server won't have a problem. If you've got a process that's eating IO and you need it, consider switching to the Xen beta. Xen is supposed to handle IO better then UML.
Only if swap thrashing is using up your IO tokens.

--James

There's plenty of I/O to go around, but nobody is allowed to run away with it. There's no need to have varying refill rates because if you're hitting the I/O limits, then 99 times out of 100 you're either swap-thrashing or your app is doing something unnecessarily inefficiently. You'd want to fix either of those even if you had dedicated hardware.

For the remaining case, when your application simply needs all that I/O, you probably simply need dedicated hardware.

A few cases where I have run into the IO limiter are (1) transferring an existing system's to a new linode and (2) pre-processing/resizing large sets of digital photos from vacations. There's nothing wrong with these tasks, but they fundamentally require a single pass sequential read or write.