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)

> > 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.

While I agree this is not impossible, tmem is designed to
be highly concurrent and the data structures manage potentially
millions of pages with thousands of pages put/got per vcpu
per domain per second.  I think just trying to deal with the
locking from a tools domain would negate any performance gain
from a GPU.  And, in any case, the overhead of tmem deduplication
is unlikely to be large enough (except possibly in contrived
cases) to be worth the work.

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