[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] cpuidle causing Dom0 soft lockups
>-----Original Message----- >From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx >[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser >Sent: Monday, February 22, 2010 9:45 PM >To: Jan Beulich; Yu, Ke >Cc: Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx >Subject: 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 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? Regards Ke _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |