> From: Dave Hansen [mailto:dave@xxxxxxxxxxxxxxxxxx] > Subject: Re: [PATCH 7/8] zswap: add to mm/ Hi Dave -- I suspect we are in violent agreement but just to make sure... Although zswap is the current example, I guess I am discussing a bigger issue, which IMHO is much more important: How should compression be utilized in the kernel (if at all)? Zswap is simply one implementation of in-kernel compression (handling anonymous pages only) and zcache is another (handling both anonymous pages and pagecache pages). Each has some limited policy, and policy defaults built-in, but neither IMHO is adequately aware of (let alone integrated with) MM policy to be useful to a broad set of end users and to be enabled by default by generic distros. > On 01/02/2013 09:26 AM, Dan Magenheimer wrote: > > However if one compares the total percentage > > of RAM used for zpages by zswap vs the total percentage of RAM > > used by slab, I suspect that the zswap number will dominate, > > perhaps because zswap is storing primarily data and slab is > > storing primarily metadata? > > That's *obviously* 100% dependent on how you configure zswap. But, that > said, most of _my_ systems tend to sit with about 5% of memory in > reclaimable slab The 5% "sitting" number for slab is somewhat interesting, but IMHO irrelevant here. The really interesting value is what percent is used by slab when the system is under high memory pressure; I'd imagine that number would be much smaller. True? > which is certainly on par with how I'd expect to see > zswap used. You are suggesting that the default zswap_max_pool_percent should be set to 5? (Current default is 20.) Zswap has little or no value on a system that would otherwise never swap. Why would you set the zswap limit so low? IMHO, even 20 may be too low. > > I don't claim to be any kind of expert here, but I'd imagine > > that MM doesn't try to manage the total amount of slab space > > because slab is "a cost of doing business". However, for > > in-kernel compression to be widely useful, IMHO it will be > > critical for MM to somehow load balance between total pageframes > > used for compressed pages vs total pageframes used for > > normal pages, just as today it needs to balance between > > active and inactive pages. > > The issue isn't about balancing. It's about reclaim where the VM only > cares about whole pages. If our subsystem (zwhatever or slab) is only > designed to reclaim _parts_ of pages, can we be successful in returning > whole pages to the VM? IMHO, it's about *both* balancing _and_ reclaim. One remaining major point of debate between zcache and zswap is that zcache accepts lower density to ensure that whole pages can be easily returned to the VM (and thus allow balancing) while zswap targets best density (by using zsmalloc) and doesn't address returning whole pages to the VM. > The slab shrinkers only work on parts of pages (singular slab objects). > Yet, it does appear that they function well enough when we try to > reclaim from them. I've never seen a slab's sizes spiral out of control > due to fragmentation. Perhaps this is because the reclaimable slab objects are mostly metadata which is highly connected to reclaimable data objects? E.g. reclaiming most reclaimable data pages also coincidentally reclaims most slab objects? (Also, it is not the slab size that would be the issue here but its density... i.e. if, after shrinking, 1000 pageframes contain only 2000 various 4-byt objects, that would be "out of control". Is there any easy visibility into slab density?) In any case, I would posit that both the nature of zpages and their average size relative to a whole page is quite unusual compared to slab. So while there may be some useful comparisons between zswap and slab, the differences may warrant dramatically different policy. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
