Messages in this thread | | | Date | Thu, 4 Jun 2015 16:28:16 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [RFC][PATCH 07/10] zsmalloc: introduce auto-compact support |
| |
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
| |