[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1588130803-20527-1-git-send-email-iamjoonsoo.kim@lge.com>
Date: Wed, 29 Apr 2020 12:26:33 +0900
From: js1304@...il.com
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Vlastimil Babka <vbabka@...e.cz>,
Laura Abbott <labbott@...hat.com>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Michal Hocko <mhocko@...e.com>,
Johannes Weiner <hannes@...xchg.org>,
Roman Gushchin <guro@...com>, Minchan Kim <minchan@...nel.org>,
Rik van Riel <riel@...riel.com>,
Christian Koenig <christian.koenig@....com>,
Huang Rui <ray.huang@....com>,
Eric Biederman <ebiederm@...ssion.com>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Pavel Machek <pavel@....cz>, kernel-team@....com,
Christoph Hellwig <hch@...radead.org>,
Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: [PATCH v2 00/10] change the implementation of the PageHighMem()
From: Joonsoo Kim <iamjoonsoo.kim@....com>
Changes on v2
- add "acked-by", "reviewed-by" tags
- replace PageHighMem() with use open-code, instead of using
new PageHighMemZone() macro. Related file is "include/linux/migrate.h"
Hello,
This patchset separates two use cases of PageHighMem() by introducing
PageHighMemZone() macro. And, it changes the implementation of
PageHighMem() to reflect the actual meaning of this macro. This patchset
is a preparation step for the patchset,
"mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" [1].
PageHighMem() is used for two different cases. One is to check if there
is a direct mapping for this page or not. The other is to check the
zone of this page, that is, weather it is the highmem type zone or not.
Until now, both the cases are the perfectly same thing. So, implementation
of the PageHighMem() uses the one case that checks if the zone of the page
is the highmem type zone or not.
"#define PageHighMem(__p) is_highmem_idx(page_zonenum(__p))"
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.
Even in this situation, PageHighMem() for the pages on the ZONE_MOVABLE
when it is called for checking the direct mapping should return correct
result. Current implementation of PageHighMem() just returns TRUE
if the zone of the page is on a highmem type zone. So, it could be wrong
if the page on the MOVABLE_ZONE is actually direct mapped.
To solve this potential problem, this patch introduces a new
PageHighMemZone() macro. In following patches, two use cases of
PageHighMem() are separated by calling proper macro, PageHighMem() and
PageHighMemZone(). Then, implementation of PageHighMem() will be changed
as just checking if the direct mapping exists or not, regardless of
the zone of the page.
Note that there are some rules to determine the proper macro.
1. If PageHighMem() is called for checking if the direct mapping exists
or not, use PageHighMem().
2. If PageHighMem() is used to predict the previous gfp_flags for
this page, use PageHighMemZone(). The zone of the page is related to
the gfp_flags.
3. If purpose of calling PageHighMem() is to count highmem page and
to interact with the system by using this count, use PageHighMemZone().
This counter is usually used to calculate the available memory for an
kernel allocation and pages on the highmem zone cannot be available
for an kernel allocation.
4. Otherwise, use PageHighMemZone(). It's safe since it's implementation
is just copy of the previous PageHighMem() implementation and won't
be changed.
My final plan is to change the name, PageHighMem() to PageNoDirectMapped()
or something else in order to represent proper meaning.
This patchset is based on next-20200428 and you can find the full patchset on the
following link.
https://github.com/JoonsooKim/linux/tree/page_highmem-cleanup-v2.00-next-20200428
Thanks.
[1]: https://lore.kernel.org/linux-mm/1512114786-5085-1-git-send-email-iamjoonsoo.kim@lge.com
Joonsoo Kim (10):
mm/page-flags: introduce PageHighMemZone()
drm/ttm: separate PageHighMem() and PageHighMemZone() use case
kexec: separate PageHighMem() and PageHighMemZone() use case
power: separate PageHighMem() and PageHighMemZone() use case
mm/gup: separate PageHighMem() and PageHighMemZone() use case
mm/hugetlb: separate PageHighMem() and PageHighMemZone() use case
mm: separate PageHighMem() and PageHighMemZone() use case
mm/page_alloc: correct the use of is_highmem_idx()
mm/migrate: replace PageHighMem() with open-code
mm/page-flags: change the implementation of the PageHighMem()
drivers/gpu/drm/ttm/ttm_memory.c | 4 ++--
drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 2 +-
drivers/gpu/drm/ttm/ttm_tt.c | 2 +-
include/linux/migrate.h | 4 +++-
include/linux/page-flags.h | 10 +++++++++-
kernel/kexec_core.c | 2 +-
kernel/power/snapshot.c | 12 ++++++------
mm/gup.c | 2 +-
mm/hugetlb.c | 2 +-
mm/memory_hotplug.c | 2 +-
mm/page_alloc.c | 4 ++--
12 files changed, 29 insertions(+), 19 deletions(-)
--
2.7.4
Powered by blists - more mailing lists