From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Tim Deegan <Tim.Deegan@citrix.com>
Cc: Xen-devel <Xen-devel@lists.xensource.com>,
Kaustubh Kabra <kaustubhwise@gmail.com>
Subject: RE: Memory de-duplication (Persistent pages)
Date: Fri, 17 Sep 2010 07:08:09 -0700 (PDT) [thread overview]
Message-ID: <30b5150b-a4f9-453e-943e-86480f47532e@default> (raw)
In-Reply-To: <20100917085503.GD11387@whitby.uk.xensource.com>
> > 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.
prev parent reply other threads:[~2010-09-17 14:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-04 19:01 Memory de-duplication (Persistent pages) Kaustubh Kabra
2010-09-06 17:35 ` Dan Magenheimer
2010-09-15 19:09 ` Kaustubh Kabra
2010-09-16 16:22 ` Dan Magenheimer
2010-09-16 18:24 ` Pasi Kärkkäinen
2010-09-16 19:34 ` Dan Magenheimer
2010-09-16 19:50 ` Pasi Kärkkäinen
2010-09-17 8:55 ` Tim Deegan
2010-09-17 14:08 ` Dan Magenheimer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30b5150b-a4f9-453e-943e-86480f47532e@default \
--to=dan.magenheimer@oracle.com \
--cc=Tim.Deegan@citrix.com \
--cc=Xen-devel@lists.xensource.com \
--cc=kaustubhwise@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).