From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx138.postini.com [74.125.245.138]) by kanga.kvack.org (Postfix) with SMTP id 150D76B006C for ; Wed, 31 Oct 2012 11:15:31 -0400 (EDT) MIME-Version: 1.0 Message-ID: <45d16955-dd1e-4975-a5b6-31e17322cad3@default> Date: Wed, 31 Oct 2012 08:15:17 -0700 (PDT) From: Dan Magenheimer Subject: RE: [PATCH 0/5] enable all tmem backends to be built and loaded as modules References: <<1351696074-29362-1-git-send-email-dan.magenheimer@oracle.com>> In-Reply-To: <<1351696074-29362-1-git-send-email-dan.magenheimer@oracle.com>> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Dan Magenheimer , devel@linuxdriverproject.org, linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, ngupta@vflare.org, konrad.wilk@oracle.com, sjenning@linux.vnet.ibm.com, minchan@kernel.org, fschmaus@gmail.com, Andor Daam , ilendir@googlemail.com, akpm@linux-foundation.org, mgorman@suse.de Apologies... I misspelled the family name of one of the Erlangen University authors of the first two patches in this patchset, so any reply-alls to any of the patch posts will see a bounce. If you reply-all to any of these patches, kindly change one of the recipients to: andor.daam@googlemail.com (was misspelled andor.damm) I regret the inconvenience... :-( > -----Original Message----- > From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com] > Sent: Wednesday, October 31, 2012 9:08 AM > To: devel@linuxdriverproject.org; linux-kernel@vger.kernel.org; gregkh@li= nuxfoundation.org; linux- > mm@kvack.org; ngupta@vflare.org; konrad.wilk@oracle.com; sjenning@linux.v= net.ibm.com; > minchan@kernel.org; dan.magenheimer@oracle.com; fschmaus@gmail.com; andor= .damm@googlemail.com; > ilendir@googlemail.com; akpm@linux-foundation.org; mgorman@suse.de > Subject: [PATCH 0/5] enable all tmem backends to be built and loaded as m= odules >=20 > Since various parts of transcendent memory ("tmem") [1] were first posted= in > 2009, reviewers have suggested that various tmem features should be built > as a module and enabled by loading the module, rather than the current cl= unky > method of compiling as a built-in and enabling via boot parameter. Due > to certain tmem initialization steps, that was not feasible at the time. >=20 > [1] http://lwn.net/Articles/454795/ >=20 > This patchset allows each of the three merged transcendent memory > backends (zcache, ramster, Xen tmem) to be used as modules by first > enabling transcendent memory frontends (cleancache, frontswap) to deal > with "lazy initialization" and, second, by adding the necessary code for > the backends to be built and loaded as modules. >=20 > The original mechanism to enable tmem backends -- namely to hardwire > them into the kernel and select/enable one with a kernel boot > parameter -- is retained but should be considered deprecated. When > backends are loaded as modules, certain knobs will now be > properly selected via module_params rather than via undocumented > kernel boot parameters. Note that module UNloading is not yet > supported as it is lower priority and will require significant > additional work. >=20 > The lazy initialization support is necessary because filesystems > and swap devices are normally mounted early in boot and these > activites normally trigger tmem calls to setup certain data structures; > if the respective cleancache/frontswap ops are not yet registered > by a back end, the tmem setup would fail for these devices and > cleancache/frontswap would never be enabled for them which limits > much of the value of tmem in many system configurations. Lazy > initialization records the necessary information in cleancache/frontswap > data structures and "replays" it after the ops are registered > to ensure that all filesystems and swap devices can benefit from > the loaded tmem backend. >=20 > Patches 1 and 2 are the original [2] patches to cleancache and frontswap > proposed by Erlangen University, but rebased to 3.7-rcN plus a couple > of bug fixes I found necessary to run properly. I have not attempted > any code cleanup. I have also added defines to ensure at runtime > that backends are not loaded as modules if the frontend patches are not > yet merged; this is useful to avoid any build dependency (since the > frontends may be merged into linux-next through different trees and > at different times than some backends) and once the entire patchset > is safely merged, these defines/ifdefs can be removed. >=20 > [2] http://www.spinics.net/lists/linux-mm/msg31490.html >=20 > Patch 3 enables module support for zcache2. Zsmalloc support > has not yet been merged into zcache2 but, once merged, could now > easily be selected via a module_param. >=20 > Patch 4 enables module support for ramster. Ramster will now be > enabled with a module_param to zcache2. >=20 > Patch 5 enables module support for the Xen tmem shim. Xen > self-ballooning and frontswap-selfshrinking are also "lazily" > initialized when the Xen tmem shim is loaded as a module, unless > explicitly disabled by module_params. >=20 > Signed-off-by: Dan Magenheimer >=20 > --- > Diffstat: >=20 > drivers/staging/ramster/Kconfig | 6 +- > drivers/staging/ramster/Makefile | 11 +- > drivers/staging/ramster/ramster.h | 6 +- > drivers/staging/ramster/ramster/nodemanager.c | 9 +- > drivers/staging/ramster/ramster/ramster.c | 29 +++- > drivers/staging/ramster/ramster/ramster.h | 2 +- > .../staging/ramster/ramster/ramster_nodemanager.h | 2 + > drivers/staging/ramster/tmem.c | 6 +- > drivers/staging/ramster/tmem.h | 8 +- > drivers/staging/ramster/zcache-main.c | 61 +++++++- > drivers/staging/ramster/zcache.h | 2 +- > drivers/xen/Kconfig | 4 +- > drivers/xen/tmem.c | 56 ++++++-- > drivers/xen/xen-selfballoon.c | 13 +- > include/linux/cleancache.h | 1 + > include/linux/frontswap.h | 1 + > include/xen/tmem.h | 8 + > mm/cleancache.c | 157 ++++++++++++++= +++-- > mm/frontswap.c | 70 ++++++++- > 19 files changed, 379 insertions(+), 73 deletions(-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org