That would definately be the best solution.

I agree an important goal will be for the Host IO usage to be optimal. Like caker said, no point in limiting IO for one linode when no other linodes need IO and there is plenty available.

But also I think more needs to be done to manage IO within one Linode. Perhaps this is a general Llinux issue and not just UML/Linode related. The thing is it's much much more important in a linode context where resources are shared. Again I am a happy camper here at Linode, but I just wanted to bring it up as an area for posisble improvement from my point of view. If I were a kernel programmer, I would do it myself and suggest the patch for inclusion, but I'm not. Before the IO Token patch, IO was a problem, and now with the patch, it's much better, but it's not ideal.

From my point of view, ideal would be being able to prioritize IO usage somehow, like CPU usage can be prioritized with nice. The bottom line is, this would produce a situation where you could have services running on hardware that was cheaper than before. There are physical hardware limits, of course, and there are software limits that can be changed once and implemented on many many servers for no additional cost (assuming open source etc). The postgres example is a case where software improvements in managing IO usage would cause me to absolutely not need a more expensive server. I know the IO capability is in the hardware, but the software side isn't able to manage it such that I can be confident enough to run that service on the same machine as an app server.

Getting the prioritization I'm after might be very hard. I say that because, to do it right, postgres itself would have to tag each IO request, for example distinguishing very low priority maintenance IO from high priority queries for web apps. But it would also involve UML, which is why I'm posting it here.

What you're asking for *does* exist. It's part of the CFQ I/O scheduler.

http://kerneltrap.org/node/view/1596

This patch has been in mainline for the past few 2.6 kernel versions, however I've never been able to get ionice to work.

My suggestion to you is to wait until the next release of UML (2.6.9) and we'll give CFQ and ionice inside UML a shot.

-Chris

Thanks, that sounds great to me. I will be looking forward to that improvement and IO bucket improvements. I didn't know an ionice patch existed, I just named the thread that cuz it sounded like a logical name.

So im corious to know if this ever got implemented or if its just one of those things that was kewl, but never got arround to happening

cheers

Yup. All the latest cfq-ts (CFQ TimeSliced) patches have the IO-nice support. It's just that cfq-ts isn't included in the vanilla kernel as of yet.

I've been holding up 2.6.11-um because of issues with porting the token-limiter to it, but I'll add cfq-ts to the list of additional patches when I build it.

-Chris