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

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

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...


> Cheers,
> [1] http://lse.sourceforge.net/locking/rcupdate.html
> -- 
> Julien Grall

Xen-devel mailing list



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