From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function
Date: Mon, 26 Feb 2018 15:50:35 +0900 [thread overview]
Message-ID: <20180226065035.GD12539@jagdpanzerIV> (raw)
In-Reply-To: <20180226055804.GD112402@rodete-desktop-imager.corp.google.com>
On (02/26/18 14:58), Minchan Kim wrote:
[..]
> > Right. The changes are pretty trivial, that's why I kept then in
> > 2 simple patches. Besides, I didn't want to mix zsmalloc and zram
> > changes.
>
> As I said earlier, it's not thing we usually do, at least, MM.
> Anyway, I don't want to insist on it because it depends each
> person's point of view what's the better for review, git-bisect.
Thanks :)
> > > size_t huge_size = _zs_huge_object(pool);
> > > ..
> > > ..
> > > if (comp_size >= huge_size)
> > > memcpy(dst, src, 4K);
> >
> > Yes, can do. My plan was to keep it completely internally to zsmalloc.
> > Who knows, it might become smart enough one day to do something more
> > than just size comparison. Any reason you used that leading underscore
>
> Let's do that in future if someone want it. :)
OK.
> > in _zs_huge_object()?
>
>
> Nope. It's just typo. Let's think better name.
> How about using zs_huge_size()?
hm, I think `huge_size' on it's own is a bit general and cryptic.
zs_huge_object_size() or zs_huge_class_size()?
-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>
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Rapoport <rppt@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function
Date: Mon, 26 Feb 2018 15:50:35 +0900 [thread overview]
Message-ID: <20180226065035.GD12539@jagdpanzerIV> (raw)
In-Reply-To: <20180226055804.GD112402@rodete-desktop-imager.corp.google.com>
On (02/26/18 14:58), Minchan Kim wrote:
[..]
> > Right. The changes are pretty trivial, that's why I kept then in
> > 2 simple patches. Besides, I didn't want to mix zsmalloc and zram
> > changes.
>
> As I said earlier, it's not thing we usually do, at least, MM.
> Anyway, I don't want to insist on it because it depends each
> person's point of view what's the better for review, git-bisect.
Thanks :)
> > > size_t huge_size = _zs_huge_object(pool);
> > > ..
> > > ..
> > > if (comp_size >= huge_size)
> > > memcpy(dst, src, 4K);
> >
> > Yes, can do. My plan was to keep it completely internally to zsmalloc.
> > Who knows, it might become smart enough one day to do something more
> > than just size comparison. Any reason you used that leading underscore
>
> Let's do that in future if someone want it. :)
OK.
> > in _zs_huge_object()?
>
>
> Nope. It's just typo. Let's think better name.
> How about using zs_huge_size()?
hm, I think `huge_size' on it's own is a bit general and cryptic.
zs_huge_object_size() or zs_huge_class_size()?
-ss
next prev parent reply other threads:[~2018-02-26 6:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-07 9:29 [PATCH 0/2] zsmalloc/zram: drop zram's max_zpage_size Sergey Senozhatsky
2018-02-07 9:29 ` Sergey Senozhatsky
2018-02-07 9:29 ` [PATCH 1/2] zsmalloc: introduce zs_huge_object() function Sergey Senozhatsky
2018-02-07 9:29 ` Sergey Senozhatsky
2018-02-08 16:30 ` Mike Rapoport
2018-02-08 16:30 ` Mike Rapoport
2018-02-09 2:55 ` Sergey Senozhatsky
2018-02-09 2:55 ` Sergey Senozhatsky
2018-02-09 4:10 ` Matthew Wilcox
2018-02-09 4:10 ` Matthew Wilcox
2018-02-09 5:04 ` Sergey Senozhatsky
2018-02-09 5:04 ` Sergey Senozhatsky
2018-02-09 5:36 ` Sergey Senozhatsky
2018-02-09 5:36 ` Sergey Senozhatsky
2018-02-09 5:48 ` Sergey Senozhatsky
2018-02-09 5:48 ` Sergey Senozhatsky
2018-02-09 11:11 ` Mike Rapoport
2018-02-09 11:11 ` Mike Rapoport
2018-02-09 12:34 ` Sergey Senozhatsky
2018-02-09 12:34 ` Sergey Senozhatsky
2018-02-10 8:23 ` [PATCHv2 " Sergey Senozhatsky
2018-02-10 8:23 ` Sergey Senozhatsky
2018-02-11 7:05 ` Mike Rapoport
2018-02-11 7:05 ` Mike Rapoport
2018-02-14 5:52 ` Sergey Senozhatsky
2018-02-14 5:52 ` Sergey Senozhatsky
2018-02-14 5:57 ` [PATCHv3 " Sergey Senozhatsky
2018-02-14 5:57 ` Sergey Senozhatsky
2018-02-20 1:24 ` Minchan Kim
2018-02-20 1:24 ` Minchan Kim
2018-02-26 5:49 ` Sergey Senozhatsky
2018-02-26 5:49 ` Sergey Senozhatsky
2018-02-26 5:58 ` Minchan Kim
2018-02-26 5:58 ` Minchan Kim
2018-02-26 6:50 ` Sergey Senozhatsky [this message]
2018-02-26 6:50 ` Sergey Senozhatsky
2018-02-26 7:46 ` Minchan Kim
2018-02-26 7:46 ` Minchan Kim
2018-02-26 8:12 ` Sergey Senozhatsky
2018-02-26 8:12 ` Sergey Senozhatsky
2018-02-07 9:29 ` [PATCH 2/2] zram: drop max_zpage_size and use zs_huge_object() Sergey Senozhatsky
2018-02-07 9:29 ` 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=20180226065035.GD12539@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=rppt@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.