Re: [PATCH 01/10] mm/page-flags: introduce PageHighMemZone()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 20, 2020 at 04:59:33PM +0900, js1304@xxxxxxxxx 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?




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux