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 RFC] memory sharing questions

To: Adin Scannell <adin@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH RFC] memory sharing questions
From: Tim Deegan <tim@xxxxxxx>
Date: Fri, 30 Sep 2011 23:46:36 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 30 Sep 2011 15:47:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAAJKtqq0Qoxh1KazXXdZaVb1qZ6pcP1LNXk1bD1tgsKEV7g_iQ@xxxxxxxxxxxxxx>
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: <CAAJKtqq0Qoxh1KazXXdZaVb1qZ6pcP1LNXk1bD1tgsKEV7g_iQ@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
At 17:46 -0400 on 30 Sep (1317404768), Adin Scannell wrote:
> Hi all,
> 
> I have a basic question about memory sharing.
> 
> What is the intended purpose of the hashtable / handle abstraction for
> page sharing?
> I understand that it's a nice to associate a handle with a
> particularly revision of a shared page, but I don't see why it's
> necessary given that whoever is calling nominate() must be aware of
> the contents of the page (post-nomination) and how many times it has
> been nominated.

The handle isn't a count of how many times the page has been nominated,
it's a global counter, incremented to be sure that the handles are
unique.  The versioning avoids race conditions where the page gets
unshared and re-shared.  Since the intended caller was the block
backend, short-cutting a read from disk by sharing the last copy read,
it's important that the mfn not have been unshared, changed and
re-shared in the meantime. 

In the current system there's only one memory-sharing caller but there
could easily be more, and it should be possible to recover from a
crashed client too. 

AIUI the caller shouldn't have to be aware of the _meaning_ of the
handle.  And there's no reason that the hash table couldn't be improved
or replaced, if there's another way around the question of whether the
page has changed since you last shared it.

Cheers,

Tim.


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

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