Re: [Xen-devel] null scheduler bug

[Dario Faggioli <dfaggioli@xxxxxxxx>]

On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> On 09/21/2018 05:20 PM, Dario Faggioli wrote:
> > 
> > What I'm after, is how log, after domain_destroy(),
> > complete_domain_destroy() is called, and whether/how it relates the
> > the
> > grace period idle timer we've added in the RCU code.
> 
> NULL scheduler and vwfi=native will inevitably introduce a latency
> when 
> destroying a domain. vwfi=native means the guest will not trap when
> it 
> has nothing to do and switch to the idle vCPU. So, in such 
> configuration, it is extremely unlikely the execute the idle_loop or 
> even enter in the hypervisor unless there are an interrupt on that
> pCPU.
> 
Ah! I'm not familiar with wfi=native --and in fact I was completely
ignoring it-- but this analysis makes sense to me.

> Per my understanding of call_rcu, the calls will be queued until the
> RCU 
> reached a threshold. We don't have many place where call_rcu is
> called, 
> so reaching the threeshold may just never happen. But nothing will
> tell 
> that vCPU to go in Xen and say "I am done with RCU". Did I miss
> anything?
> 
Yeah, and in fact we added the timer _but_, in this case, it does not
look that the timer is firing. It looks much more like "some random
interrupt happens", as you're suggesting. OTOH, in the case where there
are no printk()s, it might be that the timer does fire, but the vcpu
has not gone through Xen, so the grace period is, as far as we know,
not expired yet (which is also in accordance with Julien's analysis, as
far as I understood it).

> I have the feeling the problem might just be exacerbated the problem 
> (simlar to the idle bug with credit2) by vwfi=ative. Milan, would it
> be 
> possible to run the test without that option?
> 
Indeed. And thanks, Julien, for having a look! :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel