| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Re: [Xen-devel] Re: VM disk I/O limit patch
On Tue, Jun 28, 2011 at 01:32:14PM +0200, Florian Heigl wrote:
> 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(!!!)
Right, so you can upgrade to 3.0 or 2.6.39.
> - The patch from last week was for 2.618...
Ah, not idea who is the maintainer for the 2.6.18 tree anymore.
>
> would it be possible to add the patch to the 2.6.18-ish Xen trees and
> not into the 3.x one?
You are welcome to do this, but I don't think anybody else is going to do this.
I am definitly not going to take the patch for the 3.0 tree.
> 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-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home