Re: [Xen-devel] null scheduler bug

[Dario Faggioli <dfaggioli@xxxxxxxx>]

[Adding a few people to the Cc-list. See below...]

On Tue, 2018-09-25 at 12:15 +0100, Julien Grall wrote:
> Hi Dario,
> 
Hi,

> On 09/25/2018 10:02 AM, Dario Faggioli wrote:
> > On Mon, 2018-09-24 at 22:46 +0100, Julien Grall wrote:
> > > 
> > > 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).
> 
> The timer is only activated when sched_tick_suspend() is called.
> With 
> vwfi=native, you will never reach the idle_loop() and therefore
> never 
> setup a timer.
> 
Right.

> Milan confirmed that guest can be destroyed with vwfi=native removed.
> So 
> this is confirming my thinking. Trapping wfi will end up to switch
> to 
> idle vCPU and trigger the grace period.
> 
Indeed.

> I am not entirely sure you will be able to reproduce it on x86, but
> I 
> don't think it is a Xen Arm specific.
> 
Perhaps with something like idle=poll. But I'm not sure, as it's not
the same thing (that is for guests, while wfi=native is in Xen).

Well, IAC, I don't think we can call it an ARM issue either. It's an
issue of whatever combination of platform and configuration we support,
which we allow not to trap when the guest goes idle.

> When I looked at the code, I don't see any grace period in other
> context 
> than idle_loop. Rather than adding another grace period, I would
> just 
> force quiescence for every call_rcu.
> 
> This should not be have a big performance impact as we don't use
> much 
> call_rcu and it would allow domain to be fully destroyed in timely
> manner.
> 
I see your point, but this looks a little on the heavy side to me.
I'm not speaking of direct and measurable perf impact, but I think this
would make us diverge quite a bit from the idea of RCUs...

My knowledge of RCU themselves would need refreshing, though. I managed
to getbecome reasonably familiar with how the implementation we
imported works back then, when working on the said issue, but I guess I
better go check the code again.

I'm Cc-ing the people that have reviewed the patches and helping with
the idle timer problem, in case anyone has bright ideas out of the top
of his head.

Perhaps we should "just" get away from using RCU for domain destruction
(but I'm just tossing the idea around, without much consideration about
whether it's the right solution, or about how hard/feasible it really
is).

Or maybe we can still use the timer, in some special way, if we have
wfi=native (or equivalent)...

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