From: Minchan Kim <minchan@kernel.org>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
<linux-kernel@vger.kernel.org>, <kernel-team@lge.com>
Subject: Re: [PATCH 1/4] mm/zsmalloc: always set movable/highmem flag to the zspage
Date: Fri, 24 Mar 2017 09:34:54 +0900 [thread overview]
Message-ID: <20170324003454.GA8204@bbox> (raw)
In-Reply-To: <20170323021023.GA17486@js1304-P5Q-DELUXE>
Hi Joonsoo,
On Thu, Mar 23, 2017 at 11:10:23AM +0900, Joonsoo Kim wrote:
> On Tue, Mar 21, 2017 at 08:10:05PM +0900, Minchan Kim wrote:
> > Hi Joonsoo,
> >
> > On Thu, Mar 16, 2017 at 11:46:35AM +0900, js1304@gmail.com wrote:
> > > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> > >
> > > Zspage is always movable and is used through zs_map_object() function
> > > which returns directly accessible pointer that contains content of
> > > zspage. It is independent on the user's allocation flag.
> > > Therefore, it's better to always set movable/highmem flag to the zspage.
> > > After that, we don't need __GFP_MOVABLE/__GFP_HIGHMEM clearing in
> > > cache_alloc_handle()/cache_alloc_zspage() since there is no zs_malloc
> > > caller who specifies __GFP_MOVABLE/__GFP_HIGHMEM.
> >
> > Hmm, I wanted this when you pointed out to me firstly but when I think
> > again, I don't see it's improvement. Sorry for that.
> > The zs_malloc is exported symbol and it has gfp_t argument so user can
> > do whatever he want with any zone modifiers flags. IOW, if someuser want
> > to allocate pages from {normal|dma} zone by whatever reason, he can
> > omit __GFP_HIGHMEM from the gfp flag to fullfill the goal.
>
> Hello,
>
> I don't think that such flexibility makes things better. User cannot
> fully understand what flags are the best since it highly depends on
> implementation detail. For example, __GFP_MOVABLE is needed to
zone modifier(GFP_DMA|DMA32|HIGHMEM|MOVABLE|potentially CMA):
User can select one of zone for his goal by S/W|H/W constraint.
> optimize memory fragmentation and user cannot know it and there is no
> reason that user need to know it. __GFP_HIGHMEM is the similar case.
> He cannot know that he can pass __GFP_HIGHMEM without knowing the
> implementation detail and he cannot know the impact of __GFP_HIGHMEM
> here. So, I think that adding these flags in zsmalloc can be justified.
>
> Anyway, this patch isn't so important for this series so if you don't
> like it, I will drop it.
Yes, I don't feel strongly we need it at this moment.
Thanks.
next prev parent reply other threads:[~2017-03-24 0:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-16 2:46 [PATCH 0/4] zram: implement deduplication in zram js1304
2017-03-16 2:46 ` [PATCH 1/4] mm/zsmalloc: always set movable/highmem flag to the zspage js1304
2017-03-21 11:10 ` Minchan Kim
2017-03-23 2:10 ` Joonsoo Kim
2017-03-24 0:34 ` Minchan Kim [this message]
2017-03-16 2:46 ` [PATCH 2/4] zram: introduce zram_entry to prepare dedup functionality js1304
2017-03-16 2:46 ` [PATCH 3/4] zram: implement deduplication in zram js1304
2017-03-21 23:41 ` Minchan Kim
2017-03-23 3:04 ` Joonsoo Kim
2017-03-24 0:38 ` Minchan Kim
2017-03-23 13:40 ` Sergey Senozhatsky
2017-03-28 0:28 ` Joonsoo Kim
2017-03-16 2:46 ` [PATCH 4/4] zram: make deduplication feature optional js1304
2017-03-22 0:00 ` Minchan Kim
2017-03-23 3:05 ` Joonsoo Kim
2017-03-27 8:11 ` Sergey Senozhatsky
2017-03-28 1:02 ` Joonsoo Kim
2017-03-28 2:22 ` Sergey Senozhatsky
2017-03-28 2:50 ` Minchan Kim
2017-03-28 5:12 ` Sergey Senozhatsky
2017-03-28 5:57 ` Minchan Kim
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=20170324003454.GA8204@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=kernel-team@lge.com \
--cc=linux-kernel@vger.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 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.