[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 23.01.17 at 20:42, <julien.grall@xxxxxxx> wrote:
> Whilst testing other patches today, I have noticed that some part of the 
> resources allocated to a guest were not released during the destruction.
> 
> The configuration of the test is:
>       - ARM platform with 6 cores
>       - staging Xen with credit2 enabled by default
>       - DOM0 using 2 pinned vCPUs
> 
> The test is creating a guest vCPUs and then destroyed. After the test, 
> some resourced are not released (or could be released a long time
> after).
> 
> Looking at the code, domain resources are released in 2 phases:
>       - domain_destroy: called when there is no more reference on the domain 
> (see put_domain)
>       - complete_domain_destroy: called when the RCU is quiescent
> 
> 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)? If an upper limit is required by
a user of RCU, I think it would need to be that entity to arrange
for early expiry. I notice in this context that we don't even have
synchronize_rcu() in our sources.

Jan


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

 


Rackspace

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