> > > + 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 majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/