On 02/18/2013 03:59 PM, Dan Magenheimer wrote: >> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] >> Subject: Re: [PATCHv5 4/8] zswap: add to mm/ >> >> On 02/18/2013 01:55 PM, Dan Magenheimer wrote: >>>> From: Seth Jennings [mailto:sjenning@xxxxxxxxxxxxxxxxxx] >>>> Subject: Re: [PATCHv5 4/8] zswap: add to mm/ >>>> >>>> On 02/15/2013 10:04 PM, Ric Mason wrote: >>>>>> + * certain event is occurring. >>>>>> +*/ >>>>>> +static u64 zswap_pool_limit_hit; >>>>>> +static u64 zswap_reject_compress_poor; >>>>>> +static u64 zswap_reject_zsmalloc_fail; >>>>>> +static u64 zswap_reject_kmemcache_fail; >>>>>> +static u64 zswap_duplicate_entry; >>>>>> + >>>>>> +/********************************* >>>>>> +* tunables >>>>>> +**********************************/ >>>>>> +/* Enable/disable zswap (disabled by default, fixed at boot for >>>>>> now) */ >>>>>> +static bool zswap_enabled; >>>>>> +module_param_named(enabled, zswap_enabled, bool, 0); >>>>> >>>>> please document in Documentation/kernel-parameters.txt. >>>> >>>> Will do. >>> >>> Is that a good idea? Konrad's frontswap/cleancache patches >>> to fix frontswap/cleancache initialization so that backends >>> can be built/loaded as modules may be merged for 3.9. >>> AFAIK, module parameters are not included in kernel-parameters.txt. >> >> This is true. However, the frontswap/cleancache init stuff isn't the >> only reason zswap is built-in only. The writeback code depends on >> non-exported kernel symbols: >> >> swapcache_free >> __swap_writepage >> __add_to_swap_cache >> swapcache_prepare >> swapper_space >> end_swap_bio_write >> >> I know a fix is as trivial as exporting them, but I didn't want to >> take on that debate right now. > > Hmmm... I wonder if exporting these might be the best solution > as it (unnecessarily?) exposes some swap subsystem internals. > I wonder if a small change to read_swap_cache_async might > be more acceptable. Yes, I'm not saying that I'm for exporting them; just that that would be an easy and probably improper fix. As I recall, the only thing I really needed to change in my adaption of read_swap_cache_async(), zswap_get_swap_cache_page() in zswap, was the assumption built in that it is swapping in a page on behalf of a userspace program with the vma argument and alloc_page_vma(). Maybe if we change it to just use alloc_page when vma is NULL, that could work. In a non-NUMA kernel alloc_page_vma() equals alloc_page() so I wouldn't expect weird things doing that. Seth _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
