lkml.org 
[lkml]   [2013]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] Make frontswap+cleancache and its friend be modularized.
From
Date
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@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>




\
 
 \ /
  Last update: 2013-02-03 10:41    [W:0.155 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site