lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9df0ea91-9bff-4038-99f1-fdb80aad7147@default>
Date:	Mon, 5 Apr 2010 16:03:48 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Dmitry Torokhov <dtor@...are.com>,
	linux-kernel@...r.kernel.org, pv-drivers@...are.com
Subject: RE: [PATCH] VMware Balloon driver

> > On 04/06/2010 01:17 AM, Andrew Morton wrote:
> > >> The basic idea of the driver is to allow a guest system to give up
> > >> memory it isn't using so it can be reused by other virtual
> machines (or
> > >> the host itself).
> > >>
> > > So...  does this differ in any fundamental way from what
> hibernation
> > > does, via shrink_all_memory()?
> > >
> >
> > Just the _all_ bit, and the fact that we need to report the freed
> page
> > numbers to the hypervisor.
> >
> 
> So...  why not tweak that, rather than implementing some parallel
> thing?

I think Avi was being facetious ("_all_").  Hibernation assumes
everything in the machine is going to stop for awhile.  Ballooning
assumes that the machine has lower memory need for awhile, but
is otherwise fully operational.  Think of it as hot-plug memory
at a page granularity.

Historically, all OS's had a (relatively) fixed amount of memory
and, since it was fixed in size, there was no sense wasting any of it.
In a virtualized world, OS's should be trained to be much more
flexible as one virtual machine's "waste" could/should be another
virtual machine's "want".  Ballooning is currently the mechanism
for this; it places memory pressure on the OS to encourage it
to get by with less memory.  Unfortunately, it is difficult even
within an OS to determine what memory is wasted and what memory
might be used imminently... because LRU is only an approximation of
the future.  Hypervisors have an even more difficult problem not
only because they must infer this information from external events,
but they can double the problem if they infer the opposite of what
the OS actually does.

As Jeremy mentioned, Transcendent Memory (and its Linux implementations
"cleancache" and "frontswap") allows a guest kernel to give up memory
for the broader good while still retaining a probability that it
can get the same data back quickly.  This results in more memory
fluidity. Transcendent Memory ("tmem") still uses ballooning as
the mechanism to create memory pressure... it just provides an
insurance policy for that memory pressure.

Avi will point out that it is not clear that tmem can make use of
or benefit from tmem, but we need not repeat that discussion here.

Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ