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

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2017-01-24 at 10:50 +0000, Julien Grall wrote:
> On 24/01/2017 08:20, Jan Beulich wrote:
> > > > > On 23.01.17 at 20:42, <julien.grall@xxxxxxx> wrote:
> > > The function domain_destroy will setup the RCU callback
> > > (complete_domain_destroy) by calling call_rcu. call_rcu will add
> > > the
> > > callback into the RCU list and then will may send an IPI (see
> > > force_quiescent_state) if the threshold reached. This IPI is here
> > > to
> > > make sure all CPUs are quiescent before calling the callbacks
> > > (e.g
> > > complete_domain_destroy). In my case, the threshold has not
> > > reached and
> > > therefore an IPI is not sent.
> > 
> > But wait - isn't it the nature of RCU that it may take arbitrary
> > time
> > until the actual call(s) happen(s)?
> 
> Today this arbitrary time could be infinite if an idle pCPU does not 
> receive an interrupt. So some part of domain resource will never be
> freed.
> 
> If I am power-cycling a domain in loop, after some time the
> toolstack 
> will fail to allocate memory because of exhausted resources.
> Previous 
> instance of the domain was not yet fully destroyed (e.g 
> complete_domain_destroy was not called).
> 
Do you have a script and/or some more info for letting me try to
reproduce it (e.g., you say some otf the vCPUs are pinned, which one?
etc)?

I'm a bit curious about why you're saying this is being exposed by
using Credit2. In fact:
 1) I've power-cycled quite a few domains in these last months, while 
    under Credit2, and I don't think I have encountered it on x86;
 2) I see how it may be related to Credit2 being more deterministic 
    and not trying to schedule stuff around pseudo-randomly like 
    Credit1 does... but I'd like to try investigating a bit more.

Thanks and 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: signature.asc
Description: This is a digitally signed message part

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