Messages in this thread | | | Date | Fri, 2 Nov 2012 14:24:30 -0400 | From | Konrad Rzeszutek Wilk <> | Subject | Re: [PATCH 2/5] mm: frontswap: lazy initialization to allow tmem backends to build/run as modules |
| |
> > > + frontswap_enabled = 1; > > > > If frontswap_enabled is going to be on all the time, then what point > > does it serve? By extension, can all of the static inline wrappers in > > frontswap.h be done away with?
Hm, or the frontswap_enabled can be converted to a "frontswap_flag" which has:
#define FRONTSWAP_ON (1<<1) #define FRONTSWAP_BACKEND_ON (1<<2)
or so? And then we can see if we can squash the 'backend_registerd' and 'frontswap_enabled' together. > > The intent of frontswap_enabled and cleancache_enabled was > to avoid the overhead of a function call at the point where > each frontswap/cleancache "hooks" is placed, using a global > variable check instead. I'm not sure if this minor > performance tuning effort is worth preserving: If not, > I agree frontswap_enabled and the static inline wrappers (as > well as their cleancache brethren) could be done away with **; > if worth preserving, then I think frontswap_enabled could > be set in the init method instead but the check for enabled > in the frontswap init method and the cleancache init_fs > method would need to be removed else lazy initialization > wouldn't work.
Either way, that should be a seperate patch. > > Dan > > ** Note to anyone that tries this: There is a subtle but > clever hack in the wrappers suggested by Jeremy Fitzhardinge > that disables the wrappers at compile-time as well as > runtime. IOW, make sure you test-compile both with > CONFIG_{CLEANCACHE|FRONTSWAP} _and_ with them unconfig'd. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
| |