Re: [RFC][PATCHv2 3/8] zsmalloc: lower ZS_ALMOST_FULL waterline

From: Sergey Senozhatsky
Date: Tue Jun 16 2015 - 10:36:10 EST


On (06/16/15 22:37), Minchan Kim wrote:
> On Fri, Jun 05, 2015 at 09:03:53PM +0900, Sergey Senozhatsky wrote:
> > get_fullness_group() considers 3/4 full pages as almost empty.
> > That, unfortunately, marks as ALMOST_EMPTY pages that we would
> > probably like to keep in ALMOST_FULL lists.
> >
> > ALMOST_EMPTY:
> > [..]
> > inuse: 3 max_objects: 4
> > inuse: 5 max_objects: 7
> > inuse: 5 max_objects: 7
> > inuse: 2 max_objects: 3
> > [..]
> >
> > For "inuse: 5 max_objexts: 7" ALMOST_EMPTY page, for example,
> > it'll take 2 obj_malloc to make the page FULL and 5 obj_free to
> > make it EMPTY. Compaction selects ALMOST_EMPTY pages as source
> > pages, which can result in extra object moves.
> >
> > In other words, from compaction point of view, it makes more
> > sense to fill this page, rather than drain it.
> >
> > Decrease ALMOST_FULL waterline to 2/3 of max capacity; which is,
> > of course, still imperfect, but can shorten compaction
> > execution time.
>
> However, at worst case, once compaction is done, it could remain
> 33% fragment space while it can remain 25% fragment space in current.
> Maybe 25% wouldn't enough so we might need to scan ZS_ALMOST_FULL as
> source in future. Anyway, compaction is really slow path now so
> I prefer saving memory space by reduce internal fragmentation to
> performance caused more copy of objects.
>

Well, agree. I think we can drop this one from the series for now.
It's very hard to support this patch with any numbers, etc. because
it depends on things that are out of zram/zsmalloc control -- IO and
data patterns.

(opposing this patch is also very hard, due to exactly same reason).

-ss

> >
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@xxxxxxxxx>
> > ---
> > mm/zsmalloc.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index cd37bda..b94e281 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -198,7 +198,7 @@ static int zs_size_classes;
> > *
> > * (see: fix_fullness_group())
> > */
> > -static const int fullness_threshold_frac = 4;
> > +static const int fullness_threshold_frac = 3;
> >
> > struct size_class {
> > /*
> > @@ -633,7 +633,7 @@ static enum fullness_group get_fullness_group(struct page *page)
> > fg = ZS_EMPTY;
> > else if (inuse == max_objects)
> > fg = ZS_FULL;
> > - else if (inuse <= 3 * max_objects / fullness_threshold_frac)
> > + else if (inuse <= 2 * max_objects / fullness_threshold_frac)
> > fg = ZS_ALMOST_EMPTY;
> > else
> > fg = ZS_ALMOST_FULL;
> > --
> > 2.4.2.387.gf86f31a
> >
>
> --
> Kind regards,
> Minchan Kim
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/