From: Minchan Kim <minchan@kernel.org>
To: <js1304@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
<linux-kernel@vger.kernel.org>, <kernel-team@lge.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 1/4] mm/zsmalloc: always set movable/highmem flag to the zspage
Date: Tue, 21 Mar 2017 20:10:05 +0900 [thread overview]
Message-ID: <20170321111005.GA28016@bbox> (raw)
In-Reply-To: <1489632398-31501-2-git-send-email-iamjoonsoo.kim@lge.com>
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.
next prev parent reply other threads:[~2017-03-21 11:10 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 [this message]
2017-03-23 2:10 ` Joonsoo Kim
2017-03-24 0:34 ` Minchan Kim
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=20170321111005.GA28016@bbox \
--to=minchan@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.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.