[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] remove blocked time accounting from xen "clockchip"
>>> On 09.11.11 at 18:47, Laszlo Ersek <lersek@xxxxxxxxxx> wrote: > On 11/09/11 14:35, Jan Beulich wrote: >> That is, on an overcommitted system (and without your patch) I >> would expect you to not see the (full) double idle increment for a not >> fully idle and not fully loaded vCPU. > > I tried to verify this with an experiment. Please examine if the > experiment is bogus or not. > > On a four-PCPU host (hyperthreading off, RHEL-5.7+ hypervisor & dom0) I > started three virtual machines: > > VM1: four VCPUs, four processes running a busy loop each, independently. > VM2: ditto > VM3: single VCPU running the attached program (which otherwise puts 1/2 > load on a single CPU, virtual or physical.) OS is RHEL-6.1. > > In VM3, I also ran this script: > > $ grep cpu0 /proc/stat; sleep 20; grep cpu0 /proc/stat > cpu0 10421 0 510 119943 608 0 1 122 0 > cpu0 11420 0 510 121942 608 0 1 126 0 > > The difference in the fourth numerical column is still 1999, even though > only 10 seconds of those 20 were spent idly. > > Does the experiment miss the point (or do I), or does this disprove the > idea? For one, my expectation may be wrong (while I think the consideration of the accounting still being wrong even with the patch is correct). Second, the amount of stolen time (presumably the second to last column; not sure what kernel version RHEL-6.1 uses, so I can't immediately verify) being just 4 is certainly too small to be relevant (meaning that VM3's only vCPU got scheduled almost instantly in too many cases, which I think is the intended behavior of the credit scheduler in a contrived environment like this). To get the amount of stolen time up, I think one would have to penalize VM3 (so that it doesn't benefit from not having been scheduled for 100ms each time). I don't, however, know how to achieve that in practice. One question certainly possible to answer is whether, with your patch and across different (over-)load scenarios, process, system, idle and steal times add up to wall time, which I don't think would be the case. Which isn't to say that they do without your patch, just that it addresses only part of a wider issue. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |