Re: [Xen-devel] [PATCH v1 3/7] mm: Use statically defined locking order

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.05.16 at 17:48, <ross.lagerwall@xxxxxxxxxx> wrote:
> @@ -201,11 +203,20 @@ static inline void mm_enforce_order_unlock(int 
> unlock_level,
>  
>  /************************************************************************
>   *                                                                      *
> - * To avoid deadlocks, these locks _MUST_ be taken in the order they're *
> - * declared in this file.  The locking functions will enforce this.     *
> + * To avoid deadlocks, these locks _MUST_ be taken in the order listed  *
> + * below.  The locking functions will enforce this.                     *
>   *                                                                      *
>   ************************************************************************/
>  
> +#define MM_LOCK_ORDER_nestedp2m              10000
> +#define MM_LOCK_ORDER_p2m                    20000
> +#define MM_LOCK_ORDER_altp2mlist             30000
> +#define MM_LOCK_ORDER_altp2m                 40000
> +#define MM_LOCK_ORDER_per_page_sharing       50000
> +#define MM_LOCK_ORDER_pod                    60000
> +#define MM_LOCK_ORDER_page_alloc             70000
> +#define MM_LOCK_ORDER_paging                 80000

It would seem more natural for these to appear ahead of being used,
even if the order of #define-s doesn't really matter. And then, why
multiples of 10000? Large numbers are generally less efficient to deal
with (i.e. they can't be fit in sign-extended 8-bit immediates).

Jan


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