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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3a62a058-7976-48d7-acd2-8c6a8312f10f@default>
Date:	Sat, 1 May 2010 10:10:45 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Avi Kivity <avi@...hat.com>, Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Dave Hansen <dave@...ux.vnet.ibm.com>, Pavel Machek <pavel@....cz>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	hugh.dickins@...cali.co.uk, ngupta@...are.org, JBeulich@...ell.com,
	chris.mason@...cle.com, kurt.hackel@...cle.com,
	dave.mccracken@...cle.com, npiggin@...e.de,
	akpm@...ux-foundation.org, riel@...hat.com
Subject: RE: Frontswap [PATCH 0/4] (was Transcendent Memory): overview

> Eventually you'll have to swap frontswap pages, or kill uncooperative
> guests.  At which point all of the simplicity is gone.

OK, now I think I see the crux of the disagreement.

NO!  Frontswap on Xen+tmem never *never* _never_ NEVER results
in host swapping.  Host swapping is evil.  Host swapping is
the root of most of the bad reputation that memory overcommit
has gotten from VMware customers.  Host swapping can't be
avoided with some memory overcommit technologies (such as page
sharing), but frontswap on Xen+tmem CAN and DOES avoid it.

So, to summarize:

1) You agreed that a synchronous interface for frontswap makes
   sense for swap-to-in-kernel-compressed-RAM because it is
   truly swapping to RAM.
2) You have pointed out that an asynchronous interface for
   frontswap makes more sense for KVM than a synchronous
   interface, because KVM does host swapping.  Then you said
   if you have an asynchronous interface anyway, the existing
   swap code works just fine with no changes so frontswap
   is not needed at all... for KVM.
3) You have suggested that if Xen were more like KVM and required
   host-swapping, then Xen doesn't need frontswap either.

BUT frontswap on Xen+tmem always truly swaps to RAM.

So there are two users of frontswap for which the synchronous
interface makes sense.  I believe there may be more in the
future and you disagree but, as Jeremy said, "a general Linux
principle is not to overdesign interfaces for hypothetical users,
only for real needs."  We have demonstrated there is a need
with at least two users so the debate is only whether the
number of users is two or more than two.

Frontswap is a very non-invasive patch and is very cleanly
layered so that if it is not in the presence of either of 
the intended "users", it can be turned off in many different
ways with zero overhead (CONFIG'ed off) or extremely small overhead
(frontswap_ops is never set; or frontswap_ops is set but the
underlying hypervisor doesn't support it so frontswap_poolid
never gets set).

So... KVM doesn't need it and won't use it.  Do you, Avi, have
any other objections as to why the frontswap patch shouldn't be
accepted as is for the users that DO need it and WILL use it?
--
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