Re: xen/arm: Domain not fully destroyed when using credit2

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2679 bytes --]

On Wed, 2017-01-25 at 12:38 +0000, Julien Grall wrote:
> Hi Dario,
> 
Hey,

> On 25/01/17 11:10, Dario Faggioli wrote:
> > My point was that, still from scheduling perspective, neither
> > Credit1
> > nor Credit2 sets a wakeup timer for idle pCPUs.
> > 
> > Well, in Credit1, the master_ticker timer is never stopped (while,
> > e.g., the per-pCPU tick is stopped before entering deep sleep,
> > via sched_tick_suspend(), see commit 964fae8ac), but that's only 1
> > pCPU.
> 
> The function sched_tick_suspend is never called on ARM. The power
> saving 
> in Xen ARM is still very limited and this would need to be updated
> in 
> the future.
> 
> So I guess that's why I still see interrupt coming on the idle pCPU
> when 
> credit1 is used. 
>
Yes. If you don't suspend the tick before going to wfi/hlt/whatever,
there will be a timer firing --and AFAICT waking you up from the low
power state-- every 10ms (with default Credit1 timeslice), even for
idle pCPUs.

> Looking at credit2, the callback tick_suspend is not 
> called. Does it mean there is no per-pCPU timer?
> 
Exactly, we (happily) don't need that in Credit2. :-)

> Now, from my understanding, if we decide to call sched_tick_suspend
> on 
> ARM before idling. We will likely have the same problem with credit1 
> because there is no more interrupt to wake-up the pCPU.
> 
Basing on what you've said so far in this thread, I tend to think that,
yes, that would be the case.

> But I don't think this is an issue in the scheduler. 
>
Agreed.

> IHMO, the problem 
> is in the RCU. Indeed a CPU in lower power mode (i.e  wfi on ARM or 
> pm_idle on x86 is been executed) will never get out to tell to the
> RCU : 
> "I am quiet, go ahead". So the RCU will never be able to reclaim the 
> memory and will result on a memory exhaustion if the pCPU never
> receive 
> an interrupt (this could happen if pCPU has never ran a guest).
> 
> The question now, is how to fix it?
> 
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. :-/

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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