Re: null scheduler bug

From: Julien Grall <julien.grall@arm.com>
To: Dario Faggioli <dfaggioli@suse.com>,
	Stefano Stabellini <stefano@stabellini.net>,
	Juergen Gross <jgross@suse.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	Milan Boberic <milanboberic94@gmail.com>,
	JBeulich@suse.com, Andrew Cooper <Andrew.Cooper3@citrix.com>
Subject: Re: null scheduler bug
Date: Thu, 27 Sep 2018 16:09:55 +0100	[thread overview]
Message-ID: <acbeae1c-fda1-a079-322a-786d7528ecfc@arm.com> (raw)
In-Reply-To: <86360891f996bdb078a5eff7f860fbbb39fbc5ac.camel@suse.com>

Hi Dario,

On 09/27/2018 03:32 PM, Dario Faggioli wrote:
> On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
>> Hi,
>> I applied patch and vwfi=native and everything works fine, I can
>> create and destroy guest domain as many times as I want.
>>
> Ok, now that we know it works, what do you guys prefer?
> 
> Stefano? Julien? I know it's not strictly an ARM-only issue, but I'm
> asking you because ARM is where it shows-up/harm the most.
> 
> I personally would be ok with:
> - doing a patch adding qhimark, qlowmark and blimit boot command line
>    parameters;
> - doing a patch (similar to this one) forcing the parameters to a
>    specific state (and printing a warning about that), if wfi=native is
>    used.
> 
> Thoughts?

I know I first suggested this but I have been thinking about it and 
trying to find a different approach. With NULL scheduler, you end up 
partitioning your platform. I think may have have Xen to be there just 
for handling hypercall, emulation and guest interrupt. So I would like 
to avoid adding an interrupt when possible.

In one of your e-mail, you wrote:

"Well, our implementation of RCU requires that, from time to time, the
various physical CPUs of your box become idle, or get an interrupt, or
go executing inside Xen (for hypercalls, vmexits, etc). In fact, a CPU
going through Xen is what allow us to tell that it reached a so-called
'quiescent state', which in turns is necessary for declaring a so-
called 'RCU grace period' over."

I don't quite agree with you on the definition of "quiescent state" 
here. To take the domain example, we want to wait until all the CPU has 
stopped using the pointer (an hypercall could race put_domain). That 
pointer will not be in-use if the CPU is in kernel-mode/user-mode or in 
the idle loop. Am I correct?

So I am wondering whether we could:
	- Mark any CPU in kernel-mode/user-mode quiet
	- Raise a RCU_SOFTIRQ in call_rcu?

With that solution, it may even be possible to avoid the timer in the 
idle loop.

Cheers,

-- 
Julien Grall

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