Hello Minchan, On (03/15/16 15:17), Minchan Kim wrote: [..] > > hm, in this scenario both solutions are less than perfect. we jump > > X times over 40% margin, we have X*NR_CLASS compaction scans in the > > end. the difference is that we queue less works, yes, but we don't > > have to use workqueue in the first place; compaction can be done > > asynchronously by a pool's dedicated kthread. so we will just > > wake_up() the process. > > Hmm, kthread is over-engineered to me. If we want to create new kthread > in the system, I guess we should persuade many people to merge in. > Surely, we should have why it couldn't be done by others(e.g., workqueue). > > I think your workqueue approach is good to me. > Only problem I can see with it is we cannot start compaction when > we want instantly so my conclusion is we need both direct and > background compaction. well, if we will keep the shrinker callbacks then it's not such a huge issue, IMHO. for that type of forward progress guarantees we can have our own, dedicated, workqueue with a rescuer thread (WQ_MEM_RECLAIM). > > > If zs_free(or something) realizes current fragment is over 4M, > > > kick compacion backgroud job. > > > > yes, zs_free() is the only place that introduces fragmentation. > > > > > The job scans from highest to lower class and compact zspages > > > in each size_class until it meets high watermark(e.g, 4M + 4M /2 = > > > 6M fragment ratio). just thought... I think it'll be tricky to implement this. We scan classes from HIGH class_size to SMALL class_size, counting fragmentation value and re-calculating the global fragmentation all the time; once the global fragmentation passes the watermark, we start compacting from HIGH to SMALL. the problem here is that as soon as we calculated the class B fragmentation index and moved to class A we can't trust B anymore. classes are not locked and absolutely free to change. so the global fragmentation index likely will be inaccurate. so I'm thinking about triggering a global compaction from zs_free() (to queue less works), but instead of calculating global watermark and compacting afterwards, just compact every class that has fragmentation over XY% (for example 30%). "iterate from HI to LO and compact everything that is too fragmented". we still need some sort of a pool->compact_ts timestamp to prevent too frequent compaction jobs. -ss -- 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>