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

Re: [Xen-devel] null scheduler bug

Hi Dario,

On 09/27/2018 03:32 PM, Dario Faggioli wrote:
On Thu, 2018-09-27 at 15:15 +0200, Milan Boberic wrote:
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
- doing a patch (similar to this one) forcing the parameters to a
   specific state (and printing a warning about that), if wfi=native is


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.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.