Re: [Xen-devel] Re: Re: mapping problems in xenpaging

[Tim Deegan <tim@xxxxxxx>]

Hi, 

At 15:31 -0400 on 10 Oct (1318260666), Andres Lagar Cavilla wrote:
> On Mon, Oct 10, 2011 at 6:06 AM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> > On 10/10/2011 10:21, "Tim Deegan" <tim@xxxxxxx> wrote:
> > The best (but hard) way to make the locking cheaper is to work out a way to
> > use finer-grained locks (e.g., per-page / per-mapping) or avoid locks
> > altogether (e.g., RCU).
> No clue about RCU. But the p2m tree structure lends itself naturally
> to fine-grained locking. In fact, hierarchical locking given 2M and 1G
> superpages.
> 
> Now, this moves all the locking into the specific p2m implementations,
> ept and traditional pt. Do you think a test_and_set-style spinlock
> could fit in the unused bits of a p2m entry. It would have scarce
> debug information :) I don't know if ept would freak out with someone
> spinning on an entry it has loaded in the translation hardware.
> Probably.

I think it would be OK on EPT and on 64-bit, where there are enough
available bits in a PTE.  32-bit PTEs are full, though.  It might clash
with the AMD IOMMU as well.  ISTR that they use a different set of avail
bits so when you're using the same table for both NPT and IOMMU you have
very few spare bits. 

> So, perhaps the most decent idea is to have a tree/array of locks on
> the side. This would not have to live inside the ept/pt
> implementation-specific layer. Although locking unaligned,
> arbitrarily-sized ranges of pages (Does anyone do that? PoD?) would
> become a big headache.

I don't think anything does that, so having a tree of locks should work
fine (but might be a bit delicate to get right).  But as Keir says, we
can implement the refcounting of p2m entries first, with a single p2m
lock, and optimise afterwards -- I'm sure there will be some good way of
reducing contention.

Tim.

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