[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |