| 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
| ||
|
Date: Sun, 03 Feb 2013 02:52:00 -0600 From: Ric Mason <ric.masonn@...il.com> To: Konrad Rzeszutek Wilk <konrad@...nel.org> Cc: dan.magenheimer@...cle.com, konrad.wilk@...cle.com, sjenning@...ux.vnet.ibm.com, gregkh@...uxfoundation.org, akpm@...ux-foundation.org, ngupta@...are.org, rcj@...ux.vnet.ibm.com, linux-mm@...ck.org, linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org Subject: Re: [PATCH v2] Make frontswap+cleancache and its friend be modularized. 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@...ck.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a> -- 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