WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 5 of 9] Fine-grained concurrency control structur

To: "Tim Deegan" <tim@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH 5 of 9] Fine-grained concurrency control structure for the p2m
From: "Andres Lagar-Cavilla" <andres@xxxxxxxxxxxxxxxx>
Date: Thu, 3 Nov 2011 07:46:17 -0700
Cc: olaf@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, George Dunlap <dunlapg@xxxxxxxxx>, keir.xen@xxxxxxxxx, andres@xxxxxxxxxxxxxx, adin@xxxxxxxxxxxxxx
Delivery-date: Thu, 03 Nov 2011 07:46:46 -0700
Dkim-signature: v=1; a=rsa-sha1; c=relaxed; d=lagarcavilla.org; h= message-id:in-reply-to:references:date:subject:from:to:cc :reply-to:mime-version:content-type:content-transfer-encoding; s=lagarcavilla.org; bh=DuthbaAbU1G/LvjLHzQmE856aFQ=; b=Z3vhLFpH 7RzlEipqSehrhFGKQxDaPmIDhYpB6nmfMLasZ3kQkfXoLDT5hFpr2yEz5JH3YNvb OVosUdR1aO4csHmpML8EYoYeOqYUJ07s2P3yYyeALu1p1/iRlYZTmZ5izVpcddzl lfk7PtT0d4JSgYxj3CW5Tc7F+5vUROZRuNM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=lagarcavilla.org; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= lagarcavilla.org; b=ERxD3rB0EHIfEea6F25bBUT/dheYiousvBIRowOG1MK3 XhhwTJLYZON9K2CmyQCU3J8IbpiTuiDv5sSbjVhCpAoIQYMkn0hUSfI9l7Bs+Ox/ 1xDK9uMubJwF4Z5wHqO5K9oe3rKdjsMhwtTDWNuOFVVSVw1tkfup96CkTahtNe0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20111103142904.GD66800@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <patchbomb.1319690025@xxxxxxxxxxxxxxxxxxx> <a23e1262b1240dcabfa0.1319690030@xxxxxxxxxxxxxxxxxxx> <20111027144333.GM59656@xxxxxxxxxxxxxxxxxxxxx> <69a325bb9604ffab3cd84c4951c34641.squirrel@xxxxxxxxxxxxxxxxxxxxxxxx> <20111103142904.GD66800@xxxxxxxxxxxxxxxxxxxxx>
Reply-to: andres@xxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: SquirrelMail/1.4.21
I view PoD as a special case of paging, with sweeps implemented by the
user-space pager, etc.

But the question that lingers in my mind is what do you do in modes that
don't support ept+paging today (software shadow, amd npt).

Also, paging needs to get waitqueues before being a palatable replacement
for PoD, imho. We're aiming in that direction too.

Andres
> Hi,
>
> At 07:20 -0700 on 02 Nov (1320218409), andres@xxxxxxxxxxxxxxxx wrote:
>> > I suspect that if this is a contention point, allowing multiple
>> readers
>> > will become important, especially if there are particular pages that
>> > often get emulated access.
>> >
>> > And also, I'd  like to get some sort of plan for handling long-lived
>> > foreign mappings, if only to make sure that this phase-1 fix doesn't
>> > conflict wih it.
>> >
>>
>> If foreign mappings will hold a lock/ref on a p2m subrange, then they'll
>> disallow global operations, and you'll get a clash between log-dirty
>> and,
>> say, qemu. Ka-blam live migration.
>
> Yep.  That's a tricky one.  Log-dirty could be special-cased but I guess
> we'll have the same problem with paging, mem-event &c. :(
>
>> Read-only foreign mappings are only problematic insofar paging happens.
>> With proper p2m update/lookups serialization (global or fine-grained)
>> that
>> problem is gone.
>>
>> Write-able foreign mappings are trickier because of sharing and w^x. Is
>> there a reason left, today, to not type PGT_writable an hvm-domain's
>> page
>> when a foreign mapping happens?
>
> Unfortunately, yes.  The shadow pagetable code uses the typecount to
> detect whether the guest has any writeable mappings of the page; without
> that it would have to brute-force search all the L1 shadows in order to
> be sure that it had write-protected a page.
>
>> That would solve sharing problems. w^x
>> really can't be solved short of putting the vcpu on a waitqueue
>> (preferable to me), or destroying the mapping and forcing the foreign OS
>> to remap later. All a few steps ahead, I hope.
>
> OK, so if I understand correctly your plan is to add this mutual
> exclusion for all other users of the p2m (emulation &c) but leave
> foreign mappings alone for now, with the general plan of fixing that up
> using waitqueues.  That's OK by me.
>
>> Who/what's using w^x by the way? If the refcount is zero, I think I know
>> what I'll do ;)
>
> I think the original authors are using it in their product.  I haven't
> heard of any other users but there might be some.
>
>> What is a real problem is that pod sweeps can cause deadlocks. There is
>> a
>> simple step to mitigate this: start the sweep from the current gfn and
>> never wrap around -- too bad if the gfn is too high. But this alters the
>> sweeping algorithm. I'll deal with it when its it's turn.
>
> OK.  If there's some chance that Olaf can make PoD a special case of
> paging maybe we can get rid of the sweeps altogether (i.e., have the
> domain pause when it runs out of PoD and let the pager fix it up).  But
> I know George has spent a fair amount of time tuning the performance of
> PoD so that may not be acceptable.
>
> Cheers,
>
> Tim.
>



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

<Prev in Thread] Current Thread [Next in Thread>