From: Matthew Wilcox <willy@infradead.org>
To: js1304@gmail.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Vlastimil Babka <vbabka@suse.cz>,
Laura Abbott <labbott@redhat.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Mel Gorman <mgorman@techsingularity.net>,
Michal Hocko <mhocko@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Roman Gushchin <guro@fb.com>, Minchan Kim <minchan@kernel.org>,
Rik van Riel <riel@surriel.com>,
Christian Koenig <christian.koenig@amd.com>,
Huang Rui <ray.huang@amd.com>,
Eric Biederman <ebiederm@xmission.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Pavel Machek <pavel@ucw.cz>, Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH 01/10] mm/page-flags: introduce PageHighMemZone()
Date: Mon, 20 Apr 2020 04:20:10 -0700 [thread overview]
Message-ID: <20200420112010.GA5820@bombadil.infradead.org> (raw)
In-Reply-To: <1587369582-3882-2-git-send-email-iamjoonsoo.kim@lge.com>
On Mon, Apr 20, 2020 at 04:59:33PM +0900, js1304@gmail.com wrote:
> ZONE_MOVABLE is special. It is considered as normal type zone on
> !CONFIG_HIGHMEM, but, it is considered as highmem type zone
> on CONFIG_HIGHMEM. Let's focus on later case. In later case, all pages
> on the ZONE_MOVABLE has no direct mapping until now.
>
> However, following patchset
> "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"
> , which is once merged and reverted, will be tried again and will break
> this assumption that all pages on the ZONE_MOVABLE has no direct mapping.
> Hence, the ZONE_MOVABLE which is considered as highmem type zone could
> have the both types of pages, direct mapped and not. Since
> the ZONE_MOVABLE could have both type of pages, __GFP_HIGHMEM is still
> required to allocate the memory from it. And, we conservatively need to
> consider the ZONE_MOVABLE as highmem type zone.
I don't understand why CMA allocating pages from ZONE_MOVABLE somehow
gives these pages a direct mapping. Maybe you have a freaky layout in
the architecture that makes no sense and that's what needs to be fixed?
My understanding of the zones is based on x86, and it looks like this
on a 32-bit system with 8GB of memory:
ZONE_DMA 0-16MB
ZONE_NORMAL 16-896MB
ZONE_HIGHMEM 896-xMB
ZONE_MOVABLE x-8192MB
where x is a boot option used to partition the highmem between movable
and unmovable.
Now, why would allocating the CMA from ZONE_NORMAL suddenly make these
pages part of the direct mapping?
next prev parent reply other threads:[~2020-04-20 11:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-20 7:59 [PATCH 00/10] change the implemenation of the PageHighMem() js1304
2020-04-20 7:59 ` [PATCH 01/10] mm/page-flags: introduce PageHighMemZone() js1304
2020-04-20 11:20 ` Matthew Wilcox [this message]
2020-04-20 11:37 ` Vlastimil Babka
2020-04-21 6:43 ` Joonsoo Kim
2021-02-10 12:56 ` Prakash Gupta
2020-04-21 9:00 ` Christoph Hellwig
2020-04-22 1:02 ` Roman Gushchin
2020-04-22 7:42 ` Joonsoo Kim
2020-04-22 7:40 ` Joonsoo Kim
2020-04-20 7:59 ` [PATCH 02/10] drm/ttm: separate PageHighMem() and PageHighMemZone() use case js1304
2020-04-20 8:42 ` Christian König
2020-04-21 6:49 ` Joonsoo Kim
2020-04-20 7:59 ` [PATCH 03/10] mm/migrate: " js1304
2020-04-22 7:44 ` Christoph Hellwig
2020-04-22 7:55 ` Joonsoo Kim
2020-04-20 7:59 ` [PATCH 04/10] kexec: " js1304
2020-04-20 7:59 ` [PATCH 05/10] power: " js1304
2020-04-20 7:59 ` [PATCH 06/10] mm/gup: " js1304
2020-04-20 7:59 ` [PATCH 07/10] mm/hugetlb: " js1304
2020-04-20 7:59 ` [PATCH 08/10] mm: " js1304
2020-04-20 7:59 ` [PATCH 09/10] mm/page_alloc: correct the use of is_highmem_idx() js1304
2020-04-20 7:59 ` [PATCH 10/10] mm/page-flags: change the implementation of the PageHighMem() js1304
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=20200420112010.GA5820@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=christian.koenig@amd.com \
--cc=ebiederm@xmission.com \
--cc=guro@fb.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=js1304@gmail.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=pavel@ucw.cz \
--cc=ray.huang@amd.com \
--cc=riel@surriel.com \
--cc=rjw@rjwysocki.net \
--cc=vbabka@suse.cz \
/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;
as well as URLs for NNTP newsgroup(s).