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

[Dan Hecht <dhecht@vmware.com>]

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
>> right?
> 
> 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;
Halt;
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.

Dan