linux-kernel - Re: [GIT PULL] mm: frontswap (for 3.2 window)

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]

Date:	Thu, 3 Nov 2011 06:30:07 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Theodore Tso <tytso@....edu>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Pekka Enberg <penberg@...nel.org>,
	Cyclonus J <cyclonusj@...il.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>, ngupta@...are.org,
	Chris Mason <chris.mason@...cle.com>, JBeulich@...ell.com,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)


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….

-- Ted

--
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/