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