[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180226065035.GD12539@jagdpanzerIV>
Date: Mon, 26 Feb 2018 15:50:35 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Minchan Kim <minchan@...nel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Mike Rapoport <rppt@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Subject: Re: [PATCHv3 1/2] zsmalloc: introduce zs_huge_object() function
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
Powered by blists - more mailing lists