From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: Memory de-duplication (Persistent pages) Date: Fri, 17 Sep 2010 07:08:09 -0700 (PDT) Message-ID: <30b5150b-a4f9-453e-943e-86480f47532e@default> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100917085503.GD11387@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan Cc: Xen-devel , Kaustubh Kabra List-Id: xen-devel@lists.xenproject.org > > 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. :-) >=20 > 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. >=20 > 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.