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

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



On 22/02/2010 13:29, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 15.02.10 18:33 >>>
>> --- a/xen/common/sched_credit.c Mon Feb 15 08:19:07 2010 +0000
>> +++ b/xen/common/sched_credit.c Mon Feb 15 17:25:29 2010 +0000
>> @@ -1060,6 +1060,7 @@
>>                 /* We got a candidate. Grab it! */
>>                 CSCHED_VCPU_STAT_CRANK(speer, migrate_q);
>>                 CSCHED_STAT_CRANK(migrate_queued);
>> +                ASSERT(!vc->is_urgent);
>>                 __runq_remove(speer);
>>                 vc->processor = cpu;
>>                 return speer;
> 
> By what is this assertion motivated? I.e. why shouldn't an urgent vCPU
> be getting here? We're seeing this (BUG_ON() in the checked in version)
> trigger...

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.

 -- Keir



_______________________________________________
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®.