Re: [Xen-devel] [PATCH RFC] domctl: improve locking during domain destruction

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/04/2017 09:47 AM, Jan Beulich wrote:
>>>> On 01.09.17 at 18:28, <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 01/09/17 17:18, Jan Beulich wrote:
>>> There is no need to hold the global domctl lock while across
>>> domain_kill() - the domain lock is fully sufficient here.
>>>
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>> ---
>>> Sadly so far we haven't had any feedback on this change from the people
>>> who observed an issue apparently resulting from heavy contention here.
>>> Hence the RFC.
>>>
>>> Obviously other domctl-s could benefit from similar adjustments, so
>>> this is meant to be just a start.
>>
>> What is the expected ordering of the global domctl lock and perdomain
>> domctl locks?
> 
> I'd expect the domain locks to nest inside the global domctl one, but
> I wouldn't want to spell this out anywhere until we actually have a
> case where both need to be acquired (and I would hope such a
> case to never arise). Or (I didn't check this) maybe we already have
> cases where the per-domain lock is being acquired with the global
> domctl one being held, even without this suggested adjustment.

FWIW in the scheduler, we normally nest the global locks inside the
per-domain locks.  This actually makes more sense, as a typical usage
would be:

* Grab per-domain lock
* Figure out what's going on, what global resource we need
* Grab global lock
* Grab global resource
* Release global lock
* Finish assigning resource to current do main, do whatever else needs
to be done
* Release per-domain lock

Or to put it differently:

* The more people there are contending for a lock, the shorter the
critical section should be
* Shorter critical sections should be nested inside larger critical sections
* Global locks will have more people contending for them than per-domain
locks
* So global locks should typically be nested inside of per-domain locks.

 -George

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