[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/2] cpu steal time accounting

Keir Fraser wrote:

On 23 Feb 2006, at 08:48, Keir Fraser wrote:

One nice side effect of having this feature is that the explicit stolen
time counter (or available time counter) can be dropped entirely from
the interface, since its value can be inferred from the real time
counter and available time counter (or stolen time counter).

I don't understand the last paragraph here. It's not true that, for example,
 available_time = real_time - stolen_time

Ah, okay, I see that in fact it is. :-)

Yeah, by definition, available_time is (real_time - stolen_time).

Why not just have a halted_time instead? I think that's what we'd go for in Xen.

I assume you mean have halted_time in addition to vcpu_time, since you'd still need vcpu_time to determine stolen_time for the case a running vcpu is made to involuntarily wait.

Essentially, by adding halted_time, the Xen and VMI interfaces would be very similar in this regard. We'd have:

xen_system_time                 <==> vmi_real_time
xen_vcpu_time + xen_halted_time <==> vmi_available_time
xen_stolen_time                 <==> vmi_stolen_time

The reason the vmi does not further partition vmi_available_time into vcpu_time and halted_time is because the guest is able to correctly do this partitioning, if it chooses to do so. It can be done with:

halt_start = vmi_available_time counter;
When the vcpu starts running again,
  halt_end = vmi_available_time counter;

We know during this time, vcpu_time == 0. halted_time == (halt_end - halt_start). And, when executing outside this region, any vmi_available_time that passes is vcpu_time.

So, rather than potentially complicating the interface, the vmi leaves the partitioning of vmi_available_time into vcpu_time and halted_time up to the guest. Besides, perhaps there are other ways the guest may want to partition vmi_available_time other than into vcpu_time/halted_time, so why not leave this up to the guest OS?

Also, unless halted_time/vcpu_time is defined very carefully and precisely, having it as part of the interface can become confusing in the case the hypervisor wants to implement "halt" using a busy wait, or when the paravirtualized kernel is run on native hardware. In these cases, the vcpu is still hogging a pcpu, so it might be unclear whether to consider that time vcpu_time or halted_time.

If vcpu_time is defined to be time in which a pcpu is dedicated to the vcpu (even if the vcpu executed the "halt" interface and is busy waiting), then halted_time would be defined to be time in which no pcpu is dedicated to the vcpu but the vcpu is not involuntarily waiting (i.e. the remaining time that is not stolen). But, why expose this hypervisor implementation detail through the interface?

On the other hand, if vcpu_time is defined to be the time in which a pcpu is dedicated to the vcpu *and* the vcpu is not halted, then halted_time is defined to be the time the vcpu is halted (no matter how the hypervisor implements the halt -- a pcpu may still be dedicated to the vcpu). But, in this case, why not leave the partitioning of available_time into vcpu_time/halted_time up to the guest OS?

Just trying to say that partitioning available_time into vcpu_time and halted_time may just add confusion and make the interface more complicated without making the interface any more powerful.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.