linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joonsoo Kim <js1304@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE
Date: Mon, 22 Feb 2016 19:43:25 +0900	[thread overview]
Message-ID: <20160222104325.GA4859@swordfish> (raw)
In-Reply-To: <20160222044145.GE27829@bbox>

On (02/22/16 13:41), Minchan Kim wrote:
[..]
> > oh, sure.
> > 
> > so let's keep dynamic page allocation out of sight for now.
> > I'll do more tests with the increase ORDER and if it's OK then
> > hopefully we can just merge it, it's quite simple and shouldn't
> > interfere with any of the changes you are about to introduce.
> 
> Thanks.
> 
> And as another idea, we could try fallback approach that
> we couldn't meet nr_pages to minimize wastage so let's fallback
> to order-0 page like as-is. It will enhance, at least than now
> with small-amount of code compared to dynmaic page allocation.


speaking of fallback,
with bigger ZS_MAX_ZSPAGE_ORDER 'normal' classes also become bigger.

PATCHED

     6   128           0            1            96         78          3                1
     7   144           0            1           256        104          9                9
     8   160           0            1           128         80          5                5
     9   176           0            1           256         78         11               11
    10   192           1            1           128         99          6                3
    11   208           0            1           256         52         13               13
    12   224           1            1           512        472         28                7
    13   240           0            1           256         70         15               15
    14   256           1            1            64         49          4                1
    15   272           0            1            60         48          4                1


BASE

     6   128           0            1            96         83          3                1
     7   144           0            1           170        113          6                3
     8   160           0            1           102         72          4                2
     9   176           1            0            93         75          4                4
    10   192           0            1           128        104          6                3
    11   208           1            1            78         52          4                2
    12   224           1            1           511        475         28                4
    13   240           1            1            85         73          5                1
    14   256           1            1            64         53          4                1
    15   272           1            0            45         43          3                1


_techically_, zsmalloc is correct.
for instance, in 11 pages we can store 4096 * 11 / 176 == 256 objects.
256 * 176 == 45056, which is 4096 * 11. so if zspage for class_size 176 will contain 11
order-0 pages, we can count on 0 bytes of unused space once zspage will become ZS_FULL.

but it's ugly, because I think this will introduce bigger internal fragmentation, which,
in some cases, can be handled by compaction, but I'd prefer to touch only ->huge classes
and keep the existing behaviour for normal classes.

so I'm currently thinking of doing something like this

#define ZS_MAX_ZSPAGE_ORDER	2
#define ZS_MAX_HUGE_ZSPAGE_ORDER	4
#define ZS_MAX_PAGES_PER_ZSPAGE (_AC(1, UL) << ZS_MAX_ZSPAGE_ORDER)
#define ZS_MAX_PAGES_PER_HUGE_ZSPAGE (_AC(1, UL) << ZS_MAX_HUGE_ZSPAGE_ORDER)


so, normal classes have ORDER of 2. huge classes, however, as a fallback, can grow
up to ZS_MAX_HUGE_ZSPAGE_ORDER pages.


extend only ->huge classes: pages == 1 && get_maxobj_per_zspage(class_size, pages) == 1.

like this:

static int __get_pages_per_zspage(int class_size, int max_pages)
{
        int i, max_usedpc = 0;
        /* zspage order which gives maximum used size per KB */
        int max_usedpc_order = 1;

        for (i = 1; i <= max_pages; i++) {
                int zspage_size;
                int waste, usedpc;

                zspage_size = i * PAGE_SIZE;
                waste = zspage_size % class_size;
                usedpc = (zspage_size - waste) * 100 / zspage_size;

                if (usedpc > max_usedpc) {
                        max_usedpc = usedpc;
                        max_usedpc_order = i;
                }
        }

        return max_usedpc_order;
}

static int get_pages_per_zspage(int class_size)
{
        /* normal class first */
        int pages = __get_pages_per_zspage(class_size,
                        ZS_MAX_PAGES_PER_ZSPAGE);

        /* test if the class is ->huge and try to turn it into a normal one */
        if (pages == 1 &&
                        get_maxobj_per_zspage(class_size, pages) == 1) {
                pages = __get_pages_per_zspage(class_size,
                                ZS_MAX_PAGES_PER_HUGE_ZSPAGE);
        }

        return pages;
}

	-ss

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2016-02-22 10:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-21 13:27 [RFC][PATCH v2 0/3] mm/zsmalloc: increase objects density and reduce memory wastage Sergey Senozhatsky
2016-02-21 13:27 ` [RFC][PATCH v2 1/3] mm/zsmalloc: introduce zs_get_huge_class_size_watermark() Sergey Senozhatsky
2016-02-21 13:27 ` [RFC][PATCH v2 2/3] zram: use zs_get_huge_class_size_watermark() Sergey Senozhatsky
2016-02-22  0:04   ` Minchan Kim
2016-02-22  0:40     ` Sergey Senozhatsky
2016-02-22  1:27       ` Minchan Kim
2016-02-22  1:59         ` Sergey Senozhatsky
2016-02-22  2:05           ` Sergey Senozhatsky
2016-02-22  2:57           ` Minchan Kim
2016-02-22  3:54             ` Sergey Senozhatsky
2016-02-22  4:54               ` Minchan Kim
2016-02-22  5:05                 ` Sergey Senozhatsky
2016-02-21 13:27 ` [RFC][PATCH v2 3/3] mm/zsmalloc: increase ZS_MAX_PAGES_PER_ZSPAGE Sergey Senozhatsky
2016-02-22  0:25   ` Minchan Kim
2016-02-22  0:47     ` Sergey Senozhatsky
2016-02-22  1:34       ` Minchan Kim
2016-02-22  2:01         ` Sergey Senozhatsky
2016-02-22  2:34           ` Minchan Kim
2016-02-22  3:59             ` Sergey Senozhatsky
2016-02-22  4:41               ` Minchan Kim
2016-02-22 10:43                 ` Sergey Senozhatsky [this message]
2016-02-23  8:25                   ` Minchan Kim
2016-02-23 10:35                     ` Sergey Senozhatsky
2016-02-23 16:05                       ` Minchan Kim
2016-02-27  6:31                         ` Sergey Senozhatsky
2016-02-22  2:24         ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160222104325.GA4859@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=js1304@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox