Hello Sergey, On Tue, May 24, 2016 at 03:28:01PM +0900, Minchan Kim wrote: <snip> > > hm... zsmalloc is getting sooo complex now. > > > > `system_wq' -- can we have problems here when the system is getting > > low on memory and workers are getting increasingly busy trying to > > allocate the memory for some other purposes? > > > > _theoretically_ zsmalloc can stack a number of ready-to-release zspages, > > which won't be accessible to zsmalloc, nor will they be released. how likely > > is this? hm, can zsmalloc take zspages from that deferred release list when > > it wants to allocate a new zspage? > > Done. > > > > > do you also want to kick the deferred page release from the shrinker > > callback, for example? > > Yeb, it can be. I will do it at next revision. :) > Thanks! > I tried it now but I feel strongly we want to fix shrinker first. Now, shrinker doesn't consider VM's request(i.e., sc->nr_to_scan) but shrink all objects which could make latency huge. I want to fix it as another issue and then adding ZS_EMPTY pool pages purging logic based on it because many works for zsmalloc stucked with this patchset now which churns old code heavily. :( -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>