|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-users] Re: [Xen-devel] Re: VM disk I/O limit patch
Hi Konrad,
Thanks for providing links to info about both dm-ioband and bklio.
This is surely something to test with and might be the best choice for
Xen from 2.6.34 and up.
Question/food for thought:
since:
- 2.6.18 still has CFQ1 which has notable issues with processes
starving each other (some people have seen this and some havent, but
it exists and it's one of the worst issues that exist. Normally people
will switch to deadline scheduler and ... experience they no longer
can priorize now, and even then they'll still see their dom0 go
sluggish if a domU is too IO heavy)
- Both blkio patch and dm-ioband are not in 2.6.18 and not even in 2.6.32(!!!)
- The patch from last week was for 2.618...
would it be possible to add the patch to the 2.6.18-ish Xen trees and
not into the 3.x one?
We could have a (hopefully) working solution for a problem that exists
now on the deployments that are in use now and that could easily go
into a XenServer 5.6 Patch123456 or XCP or OracleVM.
This might also be the more time-conserving way to do it, since right
now the cgroups mechanisms in Linux are nice, but it should be obvious
that there's still a year or two to go from setting up every single
stuff via /sys after a process is started to a working solution that
can be pre-configured for all VMs.
Unless anybody thinks this is enough ;)
2011/6/27 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>:
> On Thu, Jun 23, 2011 at 01:45:36PM -0700, Shaun Reitan wrote:
>> Does this match only limit throughput or can it also limit the guest
>> by disk IOPS? christopher aker had a patch way back for UML that
>
> Just throughpout.
>
>> did disk based qos. What i really liked about that patch was that
>> it allowed for bursting by using a bucket. If i remember correctly
anything that is able to employ limits and keeps them burstable is
just perfect :)
--
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
|
|