RE: [GIT PULL] mm: frontswap (for 3.2 window)

[Dan Magenheimer]

> From: Theodore Tso [mailto:tytso@xxxxxxx]
> Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)

Hi Ted --

Thanks for your reply!
 
> On Nov 2, 2011, at 4:08 PM, Dan Magenheimer wrote:
> 
> > By "infinite" I am glibly describing any environment where the
> > data centre administrator positively knows the maximum working
> > set of every machine (physical or virtual) and can ensure in
> > advance that the physical RAM always exceeds that maximum
> > working set.  As you say, these machines need not be configured
> > with a swap device as they, by definition, will never swap.
> >
> > The point of tmem is to use RAM more efficiently by taking
> > advantage of all the unused RAM when the current working set
> > size is less than the maximum working set size.  This is very
> > common in many data centers too, especially virtualized.
> 
> That doesn't match with my experience, especially with "cloud" deployments, where in order to make the
> business plans work, the machines tend to be memory constrained, since you want to pack a large number
> of jobs/VM's onto a single machine, and high density memory is expensive and/or you are DIMM slot
> constrained.   Of course, if you are running multiple Java runtimes in each guest OS (i.e., an J2EE
> server, and another Java VM for management, and yet another Java VM for the backup manager, etc. ---
> really, I've seen cloud architectures that work that way), things get worst even faster..

Hmmm... since your memory-constrained example is highly
similar to one I use in my presentations, I _think_ we are
in total agreement, but I am confused by "doesn't match
with my experience", or maybe you are countering James'
lean data centre example?

To clarify, for a multi-tenancy environment (such as
virtualization or RAMster), tmem enables the ability
to redistribute the constrained RAM resource, i.e.
"steal from the rich and give to the poor," which is
otherwise very difficult because each kernel is a
memory hog.  Frontswap's role is really to announce
"I'm overconstrained and am about to swap to disk,
which would be embarrassing for my performance...
can someone hold this swap page for me, please?"

Dan

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