From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Mike Rapoport <rppt@linux.vnet.ibm.com>
Subject: Re: [PATCHv2 2/2] zram: drop max_zpage_size and use zs_huge_class_size()
Date: Tue, 13 Mar 2018 23:29:20 +0900 [thread overview]
Message-ID: <20180313142920.GA100978@rodete-laptop-imager.corp.google.com> (raw)
In-Reply-To: <20180313141813.GA741@tigerII.localdomain>
On Tue, Mar 13, 2018 at 11:18:13PM +0900, Sergey Senozhatsky wrote:
> On (03/13/18 22:58), Minchan Kim wrote:
> > > > If it is static, we can do this in zram_init? I believe it's more readable in that
> > > > it's never changed betweens zram instances.
> > >
> > > We need to have at least one pool, because pool decides where the
> > > watermark is. At zram_init() stage we don't have a pool yet. We
> > > zs_create_pool() in zram_meta_alloc() so that's why I put
> > > zs_huge_class_size() there. I'm not in love with it, but that's
> > > the only place where we can have it.
> >
> > Fair enough. Then what happens if client calls zs_huge_class_size
> > without creating zs_create_pool?
>
> Will receive 0.
> One of the version was returning SIZE_MAX in such case.
>
> size_t zs_huge_class_size(void)
> {
> + if (unlikely(!huge_class_size))
> + return SIZE_MAX;
> return huge_class_size;
> }
I really don't want to have such API which returns different size on
different context.
The thing is we need to create pool first to get right value.
It means zs_huge_class_size should depend on zs_create_pool.
So, I think passing zs_pool to zs_huge_class_size is right way to
prevent such misuse and confusing. Yub, franky speaknig, zsmalloc
is not popular like slab allocator or page allocator so this like
discussion would be waste. However, we don't need big effort to do
and this is review phase so I want to make more robust/readable. ;-)
>
> > I think we should make zs_huge_class_size has a zs_pool as argument.
>
> Can do, but the param will be unused. May be we can do something
Yub, param wouldn't be unused but it's the way of creating dependency
intentionally. It could make code more robust/readable.
Please, let's pass zs_pool and returns always right huge size.
> like below instead:
>
> size_t zs_huge_class_size(void)
> {
> + if (unlikely(!huge_class_size))
> + return 3 * PAGE_SIZE / 4;
> return huge_class_size;
> }
>
> Should do no harm (unless I'm missing something).
>
> -ss
next prev parent reply other threads:[~2018-03-13 14:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-06 7:06 [PATCHv2 0/2] zsmalloc/zram: drop zram's max_zpage_size Sergey Senozhatsky
2018-03-06 7:06 ` [PATCHv2 1/2] zsmalloc: introduce zs_huge_class_size() function Sergey Senozhatsky
2018-03-06 7:06 ` [PATCHv2 2/2] zram: drop max_zpage_size and use zs_huge_class_size() Sergey Senozhatsky
2018-03-13 9:02 ` Minchan Kim
2018-03-13 10:24 ` Sergey Senozhatsky
2018-03-13 13:58 ` Minchan Kim
2018-03-13 14:18 ` Sergey Senozhatsky
2018-03-13 14:29 ` Minchan Kim [this message]
2018-03-13 14:35 ` 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=20180313142920.GA100978@rodete-laptop-imager.corp.google.com \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rppt@linux.vnet.ibm.com \
--cc=sergey.senozhatsky.work@gmail.com \
--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