RE: [Xen-devel] SMP Guest Proposal RFC

[Bryan S Rosenburg <rosnbrg@xxxxxxxxxx>]

Ian Pratt writes:
> However, I'm convinced that pre-emption notifcations are not the way to
> go: Kernels typically have no way to back-out of holding a lock early,
> so giving them an active call-back is not very useful.

No one is proposing that kernels back out of holding locks early.  On receiving the notification, the kernel is expected to yield the processor when it next reaches a lock-free state.  Scheduling a thread to do the yield accomplishes that in a very clean manner.


> I think its better to have a counter that the VCPU increments whenever
> it grabs a lock and decrements when it releases a lock. When the
> pre-emption timer goes off, the hypervisor can check the counter. If its
> non zero, the hypervisor can choose to hold-off the preemption for e.g.
> 50us. It can also set a bit in another word indiciating that a
> pre-emption is pending. Whenever the '#locks held' counter is
> decremented to zero, the pre-emption pending bit can be checked, and the
> VCPU should imediately yield if it is.

This is in fact the mechanism described in Uhlig et al.  Its main drawback is that it does nothing to address the problem of user-level lock-holder preemption.  The proposed notification scheme is a single, clean mechanism that lets a kernel avoid untimely preemption of both user- and kernel-level lock holders.

- Bryan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel