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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home