Re: (un)loadable module support for zcache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/05/12 17:57, Dan Magenheimer wrote:
I think the answer here is for cleancache (and frontswap) to
support "lazy pool creation".  If a backend has not yet
registered when an init_fs/init call is made, cleancache
(or frontswap) must record the attempt and generate a valid
"fake poolid" to return.  Any calls to put/get/flush with
a fake poolid is ignored as the zcache module is not
yet loaded.  Later, when zcache is insmod'ed, it will attempt
to register and cleancache must then call the init_fs/init
routines (to "lazily" create the pools), obtain a "real poolid"
from zcache for each pool and "map" the fake poolid to the real
poolid on EVERY get/put/flush and on pool destroy (umount/swapoff).

We were thinking about how to make cleancache and frontswap able to cope with the mounting of filesystems and running of swapon when there is no backend registered without adding an indirection caused by a fake pool id map.

We figured a way to deal with this in cleancache would be to store the struct super_block pointers in an array for every call to init_fs and the uuids and struct super_blocks pointers in different arrays for every call to init_shared_fs. When a filesystem unmounts before a backend is registered, its entries in the respective arrays are removed. While no backend is registered, the put_page() and invalidate_page() are ignored and get_page() fails. As soon as a backend registers the init_fs and init_shared_fs functions are called for the struct super_block pointers (and uuids) stored in the according arrays.

For frontswap we are aiming for a similar approach by remembering the types for every call to init and failing put_page() and ignoring get_page() and invalidate_page().
Again, when a backend registers init is called for every type stored.

This should allow backends to register with cleancache and frontswap even after the mounting of filesystems and/or swapon is run. Therefore it should allow zcache to be insmodded. This would be a first step to allow rmmodding of zcache aswell.

Is this approach feasible?

Stefan, Florian, and Andor

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]