On (06/04/15 15:27), Minchan Kim wrote: [..] > > The problem is migration/freeing old zspage/allocating new zspage is > not a cheap, either. > If the system has no problem with small fragmented space, there is > no point to keep such overheads. > > So, ideal is we should trigger compaction once we realized system > is trouble but I don't have any good idea to detect it. > That's why i wanted to rely on the decision from user via > compact_threshold_ratio. that'll be extremly hard to understand knob. well, we can do something like -- don't let the number of "CLASS_ALMOST_EMPTY" to become N times greater than "CLASS_ALMOST_FULL". or -- don't let the number of pages in ZS_ALMOST_EMPTY pages to contribute 70% of class memory usage. that is 70% of all pages allocated for this class belong to ZS_ALMOST_EMPTY zspages, thus potentially we can compact it. > > > > > It's simple design of mm/compaction.c to prevent pointless overhead > > > but historically it made pains several times and required more > > > complicated logics but it's still painful. > > > > > > Other thing I found recently is that it's not always win zsmalloc > > > for zram is not fragmented. The fragmented space could be used > > > for storing upcoming compressed objects although it is wasted space > > > at the moment but if we don't have any hole(ie, fragment space) > > > via frequent compaction, zsmalloc should allocate a new zspage > > > which could be allocated on movable pageblock by fallback of > > > nonmovable pageblock request on highly memory pressure system > > > so it accelerates fragment problem of the system memory. > > > > yes, but compaction almost always leave classes fragmented. I think > > it's a corner case, when the number of unused allocated objects was > > exactly the same as the number of objects that we migrated and the > > number of migrated objects was exactly N*maxobj_per_zspage, so we > > left the class w/o any unused objects (OBJ_ALLOCATED == OBJ_USED). > > classes have 'holes' after compaction. > > > > > > > So, I want to pass the policy to userspace. > > > If we found it's really trobule on userspace, then, we need more > > > thinking. > > > > well, it can be under config "aggressive compaction" or "automatic > > compaction" option. > > > > If you really want to do it automatically without any feedback > form the userspace, we should find better algorithm. ok. I'll drop auto-compaction part for now and will resend general/minor zsmalloc tweaks today. -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>