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] Memory de-duplication (Persistent pages)

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] Memory de-duplication (Persistent pages)
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Fri, 17 Sep 2010 09:55:03 +0100
Cc: Xen-devel <Xen-devel@xxxxxxxxxxxxxxxxxxx>, Kaustubh Kabra <kaustubhwise@xxxxxxxxx>
Delivery-date: Fri, 17 Sep 2010 01:56:04 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <e25582bb-5043-4708-8b7f-ae28ec5f69ce@default>
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: <AANLkTinAdznx33YkjkHTLweZm=kdmOYXP05qP6SHwZm-@xxxxxxxxxxxxxx> <e25582bb-5043-4708-8b7f-ae28ec5f69ce@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
At 20:34 +0100 on 16 Sep (1284669257), Dan Magenheimer wrote:
> > How about things like OpenCL ?
> 
> While I know nothing about OpenCL other than a quick read
> in wikipedia, I suspect that putting an OpenCL abstraction
> layer in the hypervisor is not going to be popular with
> Xen developers. :-)

There's nothing to say that the GPU code has to live in the hypervisor.
A tools domain that was already scanning for duplicates in other
domains' memory (or for that matter in block traffic) could use whatever
GPU resources it liked.

Even in the tmem case a domain could be given read-only access to the
tmem pool (er, if IOMMUs support such a thing, which I don't recall off
the top of my head) and supply hints to the hypervisor.  That way the
hypervisor would still be scanning with the CPU but only on pages where
it was likely to succeed.

Of course there's still a question of what the memory traffic does to
performance elsewhere (and if GPU cores are going to share L3 cache with
CPUs that could make a new bottleneck) but that's not to say it wouldn't
be a win.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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