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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 31 Jan 2017, 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?

Julien, thanks for looking into this.

Instead of the RCU, could we send an interrupt to all pCPU *not* in idle
mode? We could have a shared bitmask in memory with all pCPUs currently
sleeping.


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

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