[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 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)?


Xen-devel mailing list



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