Re: [Xen-devel] [PATCH 5 of 9] x86/mm: Add per-page locking for memory sharing, when audits are disabled

["Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>]

>  >>> On 09.12.11 at 21:22, Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
> wrote:
>> With the removal of the hash table, all that is needed now is locking
>> of individual shared pages, as new (gfn,domain) pairs are removed or
>> added from the list of mappings.
>>
>> We recycle PGT_locked and use it to lock individual pages. We ensure
>> deadlock
>> is averted by locking pages in increasing order. We leverage an
>> "external"
>> order enforcing construct from mm-locks.h to ensure the p2m_lock (needed
>> to
>> modify gfn entries during sharing) is always taken after page_locks.
>
> As said before, I view taking a coarse lock inside a fine grained one as
> inappropriate, and hence recommend to not apply this patch without
> knowing if/when the promised follow-up patch will make it in.

Glad you brought that up.

The get_gfn*/put_gfn API change was brought forward as a prelude to
fully-synchronized p2m access: both lookups and modifications take a lock.
That code is not in the tree yet, because I'm fighting a few issues with
lock ordering inversions in the sharing code.

But once that code makes it in, get_gfn/put_gfn pairs delimit critical
sections protected by the p2m lock. And the sharing page_lock()s will be
nested inside those sections. In other words, p2m lock first, page lock
second, no lock inside page lock regions.

That will also require inverting the order in which locks are declared at
mm-locks.h. I hope to break through in the p2m locking during January.
Certainly before 4.2-rc1.

Thanks
Andres

>
> Jan
>
>> The global lock remains for the benefit of the auditing code, and is
>> thus enabled only as a compile-time option.
>>
>> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel