LinuxLists.cc - [PATCH v2] enable all tmem backends to be built and loaded as modules.

2012-11-14 18:58:57

Subject: [PATCH v2] enable all tmem backends to be built and loaded as modules.

There are also some patch I wrote up that are based on this patchset
that I will post soonish.

I hope these patches come out - I am travelling and not sure if my
git-send-email foo will make this work.

I copying here what Dan mentioned with some modifications by me:

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

[1] http://lwn.net/Articles/454795/

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.

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.

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.

[PATCH 1/8] mm: cleancache: lazy initialization to allow tmem
[PATCH 2/8] mm: frontswap: lazy initialization to allow tmem

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 + extra review comments.

[2] http://www.spinics.net/lists/linux-mm/msg31490.html

The other two:
[PATCH 3/8] frontswap: Make frontswap_init use a pointer for the
[PATCH 4/8] cleancache: Make cleancache_init use a pointer for the
do a bit of code cleanup that can be done to make it easier to
read and also remove some of the bools.

[PATCH 5/8] staging: zcache2+ramster: enable ramster to be
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.

[PATCH 6/8] staging: zcache2+ramster: enable zcache2 to be
Enables module support for ramster. Ramster will now be
enabled with a module_param to zcache2.

[PATCH 7/8] xen: tmem: enable Xen tmem shim to be built/loaded as a
[PATCH 8/8] xen/tmem: Remove the subsys call.
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.

Dan Magenheimer (5):
mm: cleancache: lazy initialization to allow tmem backends to build/run as modules
mm: frontswap: lazy initialization to allow tmem backends to build/run as modules
staging: zcache2+ramster: enable ramster to be built/loaded as a module
staging: zcache2+ramster: enable zcache2 to be built/loaded as a module
xen: tmem: enable Xen tmem shim to be built/loaded as a module

Konrad Rzeszutek Wilk (3):
frontswap: Make frontswap_init use a pointer for the ops.
cleancache: Make cleancache_init use a pointer for the ops
xen/tmem: Remove the subsys call.

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 | 63 ++++++--
drivers/staging/ramster/zcache.h | 2 +-
drivers/staging/zcache/zcache-main.c | 16 +-
drivers/xen/Kconfig | 4 +-
drivers/xen/tmem.c | 50 ++++--
drivers/xen/xen-selfballoon.c | 13 +-
include/linux/cleancache.h | 2 +-
include/linux/frontswap.h | 2 +-
include/xen/tmem.h | 8 +
mm/cleancache.c | 167 +++++++++++++++++---
mm/frontswap.c | 78 +++++++--
20 files changed, 371 insertions(+), 113 deletions(-)

2012-11-14 18:57:39

by Konrad Rzeszutek Wilk

[permalink] [raw]

On Mon, Nov 19, 2012 at 02:25:16PM -0800, Andrew Morton wrote:
> On Mon, 19 Nov 2012 08:53:46 +0800
> Bob Liu <[email protected]> wrote:
>
> > On Sat, Nov 17, 2012 at 7:16 AM, Andrew Morton
> > <[email protected]> wrote:
> > > On Wed, 14 Nov 2012 13:57:06 -0500
> > > Konrad Rzeszutek Wilk <[email protected]> wrote:
> > >
> > >> From: Dan Magenheimer <[email protected]>
> > >>
> > >> With the goal of allowing tmem backends (zcache, ramster, Xen tmem) to be
> > >> built/loaded as modules rather than built-in and enabled by a boot parameter,
> > >> this patch provides "lazy initialization", allowing backends to register to
> > >> frontswap even after swapon was run. Before a backend registers all calls
> > >> to init are recorded and the creation of tmem_pools delayed until a backend
> > >> registers or until a frontswap put is attempted.
> > >>
> > >>
> > >> ...
> > >>
> > >> --- a/mm/frontswap.c
> > >> +++ b/mm/frontswap.c
> > >> @@ -80,6 +80,18 @@ static inline void inc_frontswap_succ_stores(void) { }
> > >> static inline void inc_frontswap_failed_stores(void) { }
> > >> static inline void inc_frontswap_invalidates(void) { }
> > >> #endif
> > >> +
> > >> +/*
> > >> + * When no backend is registered all calls to init are registered and
> > >
> > > What is "init"? Spell it out fully, please.
> > >
> >
> > I think it's frontswap_init().
> > swapon will call frontswap_init() and in it we need to call init
> > function of backends with some parameters
> > like swap_type.
>
> Well, let's improve that comment please.
>
> > >> + * remembered but fail to create tmem_pools. When a backend registers with
> > >> + * frontswap the previous calls to init are executed to create tmem_pools
> > >> + * and set the respective poolids.
> > >
> > > Again, seems really hacky. Why can't we just change callers so they
> > > call things in the correct order?
> > >
> >
> > I don't think so, because it asynchronous.
> >
> > The original idea was to make backends like zcache/tmem modularization.
> > So that it's more convenient and flexible to use and testing.
> >
> > But currently callers like swapon only invoke frontswap_init() once,
> > it fail if backend not registered.
> > We have no way to notify swap to call frontswap_init() again when
> > backend registered in some random time
> > in future.
>
> We could add such a way?

Hey Andrew,

Sorry for the late email. Right at as you posted your questions I went on vacation :-)
Let me respond to your email and rebase the patch per your comments/ideas this week.