| Message ID | 1587369582-3882-2-git-send-email-iamjoonsoo.kim@lge.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | change the implemenation of the PageHighMem() | expand |
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?
On 4/20/20 1:20 PM, Matthew Wilcox wrote: > 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? I assume the scenario is that ZONE_MOVABLE could extend into today's ZONE_NORMAL range, which is the range covered by direct mapping. At that point, testing page's zone stops being a reliable test of "does this page have direct mapping"? I don't know the exact motivation why that will happen but I can imagine two. 1) some CMA user needs the CMA allocations to be in direct mapping range 2) the amount of CMA memory reservation required is so high it won't fit in highmem range only.
Hello, Matthew and Vlastimil. 2020년 4월 20일 (월) 오후 8:37, Vlastimil Babka <vbabka@suse.cz>님이 작성: > > On 4/20/20 1:20 PM, Matthew Wilcox wrote: > > 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? > > I assume the scenario is that ZONE_MOVABLE could extend into today's ZONE_NORMAL > range, which is the range covered by direct mapping. > At that point, testing page's zone stops being a reliable test of "does this > page have direct mapping"? Correct explanation. Thanks, Vlastimil. This patchset is a preparation for my future patchset "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE" [1] to solve the many CMA problems. CMA areas can be on the all the memory range, from ZONE_DMA to ZONE_HIGHMEM. And, in my future patchset [1], all the CMA areas are managed through the ZONE_MOVABLE and the range of the ZONE_MOVABLE is extended to cover all the CMA areas. In this case, following scenario would be possible. CMA area 1: 32MB size on the memory range 16MB~48MB (originally on the ZONE_NORMAL) CMA area 2: 32MB size on the memory range 896MB~928MB (originally on the ZONE_HIGHMEM) With my future patchset [1], ZONE_MOVABLE manages all the pages from CMA area 1 and 2. So, ZONE_MOVABLE has both direct mapped page and un-mapped page. Since one zone has two types of pages, current PageHighMem() implemented by using zone index could not work correctly. So, I make this patchset to change the PagHighMem() implementation. > I don't know the exact motivation why that will happen but I can imagine two. > 1) some CMA user needs the CMA allocations to be in direct mapping range > 2) the amount of CMA memory reservation required is so high it won't fit in > highmem range only. The range of CMA area is highly depends on system architecture and device. Each device using CMA area would have different limitation for address range and someone's limitation could be low memory range. Thanks.
I don't think the names are very good. I'd keep PageHighMem for the existing highmem zone, and add something like PageDirectMapped or similar for ay page that has a valid direct mapping address. This will also come in handy if we plan to go ahead with the xpfo work.
On Tue, Apr 21, 2020 at 02:00:05AM -0700, Christoph Hellwig wrote: > I don't think the names are very good. I'd keep PageHighMem for the > existing highmem zone, and add something like PageDirectMapped or > similar for ay page that has a valid direct mapping address. This will > also come in handy if we plan to go ahead with the xpfo work. > I agree. It also looks like the only remaining place with PageHighMem() is using "if (!PageHighMem(page))", so "if (PageDirectlyMapped(page))" would be even better. Joonsoo, the series in general looks very good to me. Please, feel free to add "Acked-by: Roman Gushchin <guro@fb.com>". Thanks!
2020년 4월 21일 (화) 오후 6:00, Christoph Hellwig <hch@infradead.org>님이 작성: > > I don't think the names are very good. I'd keep PageHighMem for the > existing highmem zone, and add something like PageDirectMapped or > similar for ay page that has a valid direct mapping address. This will > also come in handy if we plan to go ahead with the xpfo work. For PageHighMem(), as mentioned in patch description, my next plan is to rename PageHighMem() that checks valid direct mapping to PageNoDirectMapped() or something else. PageDirectMapped() looks better. Reason that rename isn't implemented in this patchset is that I'd like to rename after everything is settle down. For PageHighMemZone(), I think that it serves correct meaning. Thanks.
2020년 4월 22일 (수) 오전 10:02, Roman Gushchin <guro@fb.com>님이 작성: > > On Tue, Apr 21, 2020 at 02:00:05AM -0700, Christoph Hellwig wrote: > > I don't think the names are very good. I'd keep PageHighMem for the > > existing highmem zone, and add something like PageDirectMapped or > > similar for ay page that has a valid direct mapping address. This will > > also come in handy if we plan to go ahead with the xpfo work. > > > > I agree. It also looks like the only remaining place with PageHighMem() > is using "if (!PageHighMem(page))", so "if (PageDirectlyMapped(page))" would be > even better. As mentioned in previous reply to Christoph, I will change the name after everything is settle down. > Joonsoo, the series in general looks very good to me. Please, feel free > to add "Acked-by: Roman Gushchin <guro@fb.com>". Thanks for reviewing this! Thanks.
On 4/21/2020 12:13 PM, Joonsoo Kim wrote: > This patchset is a preparation for my future patchset "mm/cma: manage the memory > of the CMA area by using the ZONE_MOVABLE" [1] to solve the many CMA problems. > > CMA areas can be on the all the memory range, from ZONE_DMA to ZONE_HIGHMEM. > And, in my future patchset [1], all the CMA areas are managed through > the ZONE_MOVABLE > and the range of the ZONE_MOVABLE is extended to cover all the CMA > areas. In this > case, following scenario would be possible. > > CMA area 1: 32MB size on the memory range 16MB~48MB (originally on the > ZONE_NORMAL) > CMA area 2: 32MB size on the memory range 896MB~928MB (originally on > the ZONE_HIGHMEM) > > With my future patchset [1], ZONE_MOVABLE manages all the pages from > CMA area 1 and 2. > So, ZONE_MOVABLE has both direct mapped page and un-mapped page. Since one zone > has two types of pages, current PageHighMem() implemented by using > zone index could not > work correctly. So, I make this patchset to change the PagHighMem() > implementation. Hello Joonsoo, Resurrecting this thread. I wanted to check if you are still working on [1]. If yes, would you be posting it soon. I think these would be useful for high CMA system. Thanks, Prakash
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h index 222f6f7..fca0cce 100644 --- a/include/linux/page-flags.h +++ b/include/linux/page-flags.h @@ -378,10 +378,16 @@ PAGEFLAG(Readahead, reclaim, PF_NO_COMPOUND) /* * Must use a macro here due to header dependency issues. page_zone() is not * available at this point. + * PageHighMem() is for checking if the direct mapping exists or not. + * PageHighMemZone() is for checking the zone, where the page is belong to, + * in order to predict previous gfp_flags or to count something for system + * memory management. */ #define PageHighMem(__p) is_highmem_idx(page_zonenum(__p)) +#define PageHighMemZone(__p) is_highmem_idx(page_zonenum(__p)) #else PAGEFLAG_FALSE(HighMem) +PAGEFLAG_FALSE(HighMemZone) #endif #ifdef CONFIG_SWAP