WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] cpuidle causing Dom0 soft lockups

>>> "Yu, Ke" <ke.yu@xxxxxxxxx> 23.02.10 10:32 >>>
>>The author's assertion was that vc must be runnable and hence cannot be
>>polling and hence cannot be is_urgent. It sounded dodgy to me hence I
>>upgarded it to a BUG_ON(), but couldn't actually eyeball a way in which
>>vc->is_urgent could be true at that point in the code. We have the lock on
>>the peer cpu's schedule_lock, so is_urgent cannot change under our feet, and
>>vc is not running so it cannot be added to the domain's poll_mask under our
>>feet.

>Right. According to the code, there should be no way to this BUG_ON.
>If it happens, that reveal either bugs of code or the necessity of
>adding code to migrate urgent vcpu count. Do you have more
>information on how this BUG_ON happens?

Obviously there are vCPU-s that get inserted on a run queue with
is_urgent set (which according to my reading of Keir's description
shouldn't happen). In particular, this

--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -201,6 +201,7 @@ __runq_insert(unsigned int cpu, struct c
 
     BUG_ON( __vcpu_on_runq(svc) );
     BUG_ON( cpu != svc->vcpu->processor );
+WARN_ON(svc->vcpu->is_urgent);//temp
 
     list_for_each( iter, runq )
     {

triggers occasionally:

(XEN) Xen call trace:
(XEN)    [<ffff82c48011a1e8>] csched_vcpu_wake+0x1e8/0x200
(XEN)    [<ffff82c48011dde2>] vcpu_wake+0x152/0x3a0
(XEN)    [<ffff82c48014b6cd>] vcpu_kick+0x1d/0x80
(XEN)    [<ffff82c480108465>] evtchn_set_pending+0x145/0x1d0
(XEN)    [<ffff82c4801087e8>] evtchn_send+0xa8/0x150
(XEN)    [<ffff82c480108de2>] do_event_channel_op+0x552/0x10d0
(XEN)    [<ffff82c4801f3b61>] do_iret+0xc1/0x1a0
(XEN)    [<ffff82c4801ef169>] syscall_enter+0xa9/0xae

As I understand it, a vCPU with is_urgent set being on any run
queue is enough for the questionable BUG_ON() to eventually
trigger.

Jan


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