Re: [PATCH v2] Make frontswap+cleancache and its friend bemodularized.

[Ric Mason]

Hi Konrad,
On Fri, 2013-02-01 at 15:22 -0500, Konrad Rzeszutek Wilk wrote:

I have already enable frontswap,cleancache,zcache,
 FRONTSWAP [=y]  
 CLEANCACHE [=y]
 ZCACHE [=y]
But all of knode under /sys/kernel/debug/frontswap and cleancache still
zero, my swap device is enable, where I miss?

> Parts of this patch have been posted in the post (way back in November), but
> this patchset expanded it a bit. The goal of the patches is to make the
> different frontswap/cleancache API backends be modules - and load way way after
> the swap system (or filesystem) has been initialized. Naturally one can still
> build the frontswap+cleancache backend devices in the kernel. The next goal
> (after these patches) is to also be able to unload the backend drivers - but
> that places some interesting requirements to "reload" the swap device with
> swap pages (don't need to worry that much about cleancache as it is a "secondary"
> cache and can be dumped). Seth had posted some patches for that in the zswap
> backend - and they could be more generally repurporsed.
> 
> Anyhow, I did not want to lose the authorship of some of the patches so I
> didn't squash the ones that were made by Dan and mine. I can do it for review
> if it would make it easier, but from my recollection on how Linus likes things
> run he would prefer to keep the history (even the kludge parts).
> 
> The general flow prior to these patches was [I am concentrating on the
> frontswap here, but the cleancache is similar, just s/swapon/mount/]:
> 
>  1) kernel inits frontswap_init
>  2) kernel inits zcache (or some other backend)
>  3) user does swapon /dev/XX and the writes to the swap disk end up in
>     frontswap and then in the backend.
> 
> With the module loading, the 1) is still part of the bootup, but the
> 2) or 3) can be run at anytime. This means one could load the backend
> _after_ the swap disk has been initialized and running along. Or
> _before_ the swap disk has been setup - but that is similar to the
> existing case so not that exciting.
> 
> To deal with that scenario the frontswap keeps an queue (actually an atomic
> bitmap of the swap disks that have been init) and when the backend registers -
> frontswap runs the backend init on the queued up swap disks.
> 
> The interesting thing is that we can be to certain degree racy when the
> swap system starts steering pages to frontswap. Meaning after the backend
> has registered it is OK if the pages are still hitting the disk instead of
> the backend. Naturally this is unacceptable if one were to unload the
> backend (not yet supported) - as we need to be quite atomic at that stage
> and need to stop processing the pages the moment the backend is being
> unloaded. To support this, the frontswap is using the struct static_key
> which are incredibly light when they are in usage. They are incredibly heavy
> when the value switches (on/off), but that is OK. The next part of unloading is
> also taking the pages that are in the backend and feed them in the swap
> storage (and Seth's patches do some of this).
> 
> Also attached is one patch from Minchan that fixes the condition where the
> backend was constricted in allocating memory at init - b/c we were holding
> a spin-lock. His patch fixes that and we are just holding the swapon_mutex
> instead. It has been rebased on top of my patches.
> 
> This patchset is based on Greg KH's staging tree (since the zcache2 has
> now been renamed to zcache). To be exact, it is based on
> 085494ac2039433a5df9fdd6fb653579e18b8c71
> 
> Dan Magenheimer (4):
>       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: zcache: enable ramster to be built/loaded as a module
>       xen: tmem: enable Xen tmem shim to be built/loaded as a module
> 
> Konrad Rzeszutek Wilk (10):
>       frontswap: Make frontswap_init use a pointer for the ops.
>       cleancache: Make cleancache_init use a pointer for the ops
>       staging: zcache: enable zcache to be built/loaded as a module
>       xen/tmem: Remove the subsys call.
>       frontswap: Remove the check for frontswap_enabled.
>       frontswap: Use static_key instead of frontswap_enabled and frontswap_ops
>       cleancache: Remove the check for cleancache_enabled.
>       cleancache: Use static_key instead of cleancache_ops and cleancache_enabled.
>       zcache/tmem: Better error checking on frontswap_register_ops return     value.
>       xen/tmem: Add missing %s in the printk statement.
> 
> Minchan Kim (1):
>       frontswap: Get rid of swap_lock dependency
> 
> 
>  drivers/staging/zcache/Kconfig                     |   6 +-
>  drivers/staging/zcache/Makefile                    |  11 +-
>  drivers/staging/zcache/ramster.h                   |   6 +-
>  drivers/staging/zcache/ramster/nodemanager.c       |   9 +-
>  drivers/staging/zcache/ramster/ramster.c           |  29 ++-
>  drivers/staging/zcache/ramster/ramster.h           |   2 +-
>  .../staging/zcache/ramster/ramster_nodemanager.h   |   2 +
>  drivers/staging/zcache/tmem.c                      |   6 +-
>  drivers/staging/zcache/tmem.h                      |   8 +-
>  drivers/staging/zcache/zcache-main.c               |  64 +++++-
>  drivers/staging/zcache/zcache.h                    |   2 +-
>  drivers/xen/Kconfig                                |   4 +-
>  drivers/xen/tmem.c                                 |  55 +++--
>  drivers/xen/xen-selfballoon.c                      |  13 +-
>  include/linux/cleancache.h                         |  27 ++-
>  include/linux/frontswap.h                          |  31 +--
>  include/xen/tmem.h                                 |   8 +
>  mm/cleancache.c                                    | 241 ++++++++++++++++++---
>  mm/frontswap.c                                     | 121 ++++++++---
>  mm/swapfile.c                                      |   7 +-
>  20 files changed, 505 insertions(+), 147 deletions(-)
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


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