Re: [Xen-users] Transcendent Memory ("tmem") -capable kernel now publicly released

[Phillip Susi <psusi@xxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/16/2012 04:11 PM, Dan Magenheimer wrote:
> That weird ASCII text is intended to allow the hypervisor to
> communicate with userland in a fully-backwards-and-forwards-compatible
> way.  It must be parsed by a userland program, i.e.:
> 
> # xm tmem-list --long --all | /usr/sbin/xen-tmem-list-parse
> 
> I usually surround the above with 'watch -d "<above commands>"'
> in a big window to watch things change.  Dunno if ubuntu
> has the watch command though.
> 
> (If the parsing program isn't at that location, it may not be
> built or maybe is installed elsewhere on a Debian-ish system.
> See the source for it in xen source in xen/tools/misc.)

I'm curious as to why the parser is a separate utility instead of just being 
the normal output of the management tool, with an optional --machine-parsable 
switch to fall back to the current behavior.

> The parsed output has a huge amount of detail so is still mostly
> undecipherable to mortals.  The key data can also be watched in
> xentop (aka "xm top")... press "t" for tmem data (which will
> show up only if any of the key values are non-zero).  Also
> in xentop, you can watch selfballooning working.  (Note
> "xm list" has had a bug forever so doesn't show "current memory"
> just the memory the domain was launched with.)

Now THAT sounds like what I have been looking for.  I'll have to check it out.

> For ephemeral pools (i.e. via cleancache), "gets" are destructive,
> so the page of data is moved (removed from tmem) on a successful get.
> So no duplication.  For persistent pools (i.e. via frontswap),
> "gets" are non-destructive, so the page of data is copied from tmem
> on a successful get, which mimics a swap device, thus the name
> "persistent"; a "flush" is required to destroy persistent pages of data.

Hrm... I thought one of the advantages of tmem was that when multiple domains 
happen to be caching the same data, the page only needs to be kept in ram once. 
 If get moves the page out of tmem and into the domain, that would seem to 
preclude that.  Also I understand that tmem can compress the data, in which 
case it doesn't seem possible to do a move as the data must first be 
decompressed.

> P.S. Although Xen tmem will work without frontswap, I don't recommend it
> (esp selfballooning) without frontswap.  Selfballooning can be aggressive
> and may sometimes cause swapping, which is absorbed by frontswap
> instead of going to a swap disk.  That's why the Oracle UEK2 kernel
> includes frontswap even though it isn't upstream yet, see
> http://lwn.net/Articles/465317/ (we'll be trying upstream again soon).

I'll have to try and find the patch series somewhere and merge it into my local 
Ubuntu git tree.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPjNu5AAoJEJrBOlT6nu75pZsH/1XSdxQyLS0b7xhZIi4VkQRB
36dKAgYaxQsyF+Y3FAJQjWP9Z4XS4YyycbnCtP02ZwJOwmAsSuBA6XHrdnLxMOKQ
tk5VoAomSWmnD+A3wAIat/IyvNioGrh1PfltmcAk/iifGCWAquHZHuKpd0IVMllG
cDjhRKJgZ5M24w1BRp276BW+UX1mj+InQJOLI7QQwv6eLvrbaVIHlpmeG0/E8BlY
5y1NXZAHKfKaqY3X/3Iq+gyM6Baqa5herGiAPNfo4KlQMtOj3t5Mdf0+++sXIDC/
J7cH6Ux/GFE0QImQ19MZ+O++8gAQYgL+VOLccmWmYhvtHPQ7agMyrzgLFHU4xw0=
=wrIj
-----END PGP SIGNATURE-----

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users