[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2 of 3] Make p2m lookups fully synchronized wrt modifications



At 08:33 -0800 on 02 Dec (1322814798), Andres Lagar-Cavilla wrote:
> > At 08:41 -0800 on 24 Nov (1322124101), Andres Lagar-Cavilla wrote:
> >> Here is one solution to consider: do not lock the p2m on lookups in
> >> shadow
> >> mode. Shadow mode does not support paging out and sharing of pages,
> >> which
> >> are primary reasons why we want synchronized p2m lookups. The hap cases
> >> where there is an inversion of the p2m_lock -> paging_lock order are
> >> reasonably simple to handle.
> >>
> >> The other option is to invert the order and place paging_lock ->
> >> p2m_lock,
> >> but that will raise another set of potential inversions. I think this is
> >> a
> >> no go.
> >
> > Is there scope for having the p2m lock split out into the overall one
> > (needed for allocations &c) and the per-record ones, and have them at
> > different levels in the lock hierarchy?
> I think it's saner to go with one big lock and then shard it if we run
> into performance problems. Your proposal, actually :)
> 
> Now, I'm thinking of splitting ... the paging lock. It covers way too much
> ground right now, and many of these inversions would become more
> tractable. Thinking of paging_alloc_lock, paging_logdirty_lock,
> paging_lock.

...almost exactly six months after I merged the shadow, hap and
log-dirty locks into one lock, to avoid the deadlocks that were caused
by those sections of code calling in to each other. :)

http://xenbits.xen.org/hg/staging/xen-unstable.hg/log?rev=2bbed

Tim.

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


 


Rackspace

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