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

RE: [Xen-devel] [PATCH] remove HVM halt timer


  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Li, Xin B" <xin.b.li@xxxxxxxxx>
  • Date: Fri, 10 Nov 2006 16:34:03 +0800
  • Delivery-date: Fri, 10 Nov 2006 00:34:26 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccEnswNUkAD/BhaQT+W4uZ/emiWdAAAYqyKAABK//A=
  • Thread-topic: [Xen-devel] [PATCH] remove HVM halt timer

>
>> remove HVM halt timer.
>> It's no longer needed since interrupts can wake it up now; using
>> vcpu_unblock instead of vcpu_kick because timer callback 
>functions are
>> executed on the precossor the target vcpu is on.
>
>Why do you replace use of the schedop_block hypercall with 
>direct setting of the blocked flag and softirq?

Currently there are 3 points where vmx may gets schuduled out:
1) just before vmentry in exits.S
2) wait_on_xen_event_channel in hvm_do_resume, but I think now it's
never reachable.
3) in hvm_hlt.
Actually 3 can be merged into 1, and we can do some statistic jobs
there.
See prepare_wait_on_xen_event_channel, it's the same way.

>Also vcpu_kick() has negligible extra cost compared with vcpu_unblock()
and it's less confusing just to use it
>everywhere. Most people don't remember the semantic difference.
>

OK, I'll change back to use vcpu_kick, I also feel vcpu_unblock is
somewhat misleading .
-Xin

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


 


Rackspace

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