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

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2



Hi,

On 02/02/17 11:53, Wei Liu wrote:
On Thu, Feb 02, 2017 at 04:22:53AM -0700, Jan Beulich wrote:
On 01.02.17 at 19:21, <wei.liu2@xxxxxxxxxx> wrote:
On Tue, Jan 31, 2017 at 04:30:50PM +0000, Julien Grall wrote:
Hi Dario,

On 25/01/17 16:00, Dario Faggioli wrote:
On Wed, 2017-01-25 at 12:38 +0000, Julien Grall wrote:
On 25/01/17 11:10, Dario Faggioli wrote:
And a good one. I may be wrong (I certainly wasn't around at the time),
but ISTR out RCU code is imported/inspired by Linux... Looking there
again may help, but, nowadays, Linux RCU subsystem is a Lernaean Hydra
monster, with 100 heads and sharpen claws! :-O

And, while, in there, it has to be like that, I don't think we need all
such complexity, and hence we can't just re-sync. :-/

Yeah, even the tiny RCU code is quite complex :/. I've looked at our RCU
code and noticed there is a link in the header to [1].

It seems to be a documentation about the RCU code we used. From my
understanding of the "RCU Implementations", the authors are expecting a
timer to kick periodically pCPU and check if there is some RCU work pending.

We could add this timer but it would prevent an idle pCPU to stay in low
power mode for a long time. Another solution would be to send an interrupt
to each pCPU when call_rcu is called rather depending on a mark. Although
this would still wake-up the pCPU even it was doing nothing.

Any better ideas?

Worth checking all the RCU docs in Linux (Documentation/RCU).

I think there are descriptions about idle or no-tick variants. It would
be useful to know how Linux handles this. I suspect RCU in Linux is more
capable than the one in Xen...

Isn't all we need an rcu_idle_{enter,exit}() implementation (and of
course calls to them placed where needed)?


I'm no RCU expert, but having checked Linux source code and the
documentation of rcu_idle_{enter,exit}, what you said makes sense to me.

And the doc seems to confirm that (see Documentation/RCU/rcu.txt):

"Just as with spinlocks, RCU readers are not permitted to
block, switch to user-mode execution, or enter the idle loop.
Therefore, as soon as a CPU is seen passing through any of these
three states, we know that that CPU has exited any previous RCU
read-side critical sections.  So, if we remove an item from a
linked list, and then wait until all CPUs have switched context,
executed in user mode, or executed in the idle loop, we can
safely free up that item."

Dario, are you going to look into the issue? Or shall I try to write a patch for it?

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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