From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx162.postini.com [74.125.245.162]) by kanga.kvack.org (Postfix) with SMTP id E932B6B0022 for ; Thu, 28 Feb 2013 01:13:25 -0500 (EST) Received: by mail-ia0-f178.google.com with SMTP id y26so1213139iab.37 for ; Wed, 27 Feb 2013 22:13:25 -0800 (PST) Message-ID: <512EF580.6000608@gmail.com> Date: Thu, 28 Feb 2013 14:13:20 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: mm: introduce new field "managed_pages" to struct zone Content-Type: multipart/alternative; boundary="------------030107020007060906080805" Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu , Jiang Liu Cc: "linux-mm@kvack.org >> Linux Memory Management List" This is a multi-part message in MIME format. --------------030107020007060906080805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jiang, https://patchwork.kernel.org/patch/1781291/ You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? --------------030107020007060906080805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jiang,

https://patchwork.kernel.org/patch/1781291/

You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this?
--------------030107020007060906080805-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx130.postini.com [74.125.245.130]) by kanga.kvack.org (Postfix) with SMTP id 1C1346B0002 for ; Sun, 3 Mar 2013 00:01:19 -0500 (EST) Received: by mail-oa0-f46.google.com with SMTP id k1so7676992oag.5 for ; Sat, 02 Mar 2013 21:01:18 -0800 (PST) Message-ID: <5132D918.2000009@gmail.com> Date: Sun, 03 Mar 2013 13:01:12 +0800 From: Ric Mason MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> In-Reply-To: <512EF580.6000608@gmail.com> Content-Type: multipart/alternative; boundary="------------050603060800000005010502" Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" , Andrew Morton , Yinghai Lu This is a multi-part message in MIME format. --------------050603060800000005010502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/28/2013 02:13 PM, Simon Jeons wrote: > Hi Jiang, > > https://patchwork.kernel.org/patch/1781291/ > > You said that the bootmem allocator doesn't touch *highmem pages*, so > highmem zones' managed_pages is set to the accurate value > "spanned_pages - absent_pages" in function free_area_init_core() and > won't be updated anymore. Why it doesn't touch *highmem pages*? Could > you point out where you figure out this? Yeah, why bootmem doesn't touch highmem pages? The patch is buggy. :( --------------050603060800000005010502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/28/2013 02:13 PM, Simon Jeons wrote:
Hi Jiang,

https://patchwork.kernel.org/patch/1781291/

You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this?

Yeah, why bootmem doesn't touch highmem pages? The patch is buggy. :(
--------------050603060800000005010502-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx148.postini.com [74.125.245.148]) by kanga.kvack.org (Postfix) with SMTP id 1B2F16B0002 for ; Sun, 3 Mar 2013 10:43:59 -0500 (EST) Received: by mail-pb0-f51.google.com with SMTP id un15so2590221pbc.24 for ; Sun, 03 Mar 2013 07:43:58 -0800 (PST) Message-ID: <51336FB4.9000202@gmail.com> Date: Sun, 03 Mar 2013 23:43:48 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> In-Reply-To: <512EF580.6000608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" Hi Simon, Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel can't directly access highmem pages. Regards! Gerry On 02/28/2013 02:13 PM, Simon Jeons wrote: > Hi Jiang, > > https://patchwork.kernel.org/patch/1781291/ > > You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx136.postini.com [74.125.245.136]) by kanga.kvack.org (Postfix) with SMTP id 717C16B0007 for ; Sun, 3 Mar 2013 12:13:29 -0500 (EST) Received: by mail-pb0-f49.google.com with SMTP id xa12so2587657pbc.8 for ; Sun, 03 Mar 2013 09:13:28 -0800 (PST) Message-ID: <513384B2.9090308@gmail.com> Date: Mon, 04 Mar 2013 01:13:22 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <5132D918.2000009@gmail.com> In-Reply-To: <5132D918.2000009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ric Mason Cc: Simon Jeons , Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" , Andrew Morton , Yinghai Lu On 03/03/2013 01:01 PM, Ric Mason wrote: > On 02/28/2013 02:13 PM, Simon Jeons wrote: >> Hi Jiang, >> >> https://patchwork.kernel.org/patch/1781291/ >> >> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? > > Yeah, why bootmem doesn't touch highmem pages? The patch is buggy. :( > Actually I found that assumption may be wrong for some architectures, and I'm working on a patchset to clean it up. BTW, what's the issue with that patch? Regards! Gerry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx124.postini.com [74.125.245.124]) by kanga.kvack.org (Postfix) with SMTP id 510B56B0002 for ; Sun, 3 Mar 2013 18:57:16 -0500 (EST) Received: by mail-ie0-f178.google.com with SMTP id c13so5398831ieb.23 for ; Sun, 03 Mar 2013 15:57:15 -0800 (PST) Message-ID: <5133E356.6000502@gmail.com> Date: Mon, 04 Mar 2013 07:57:10 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> In-Reply-To: <51336FB4.9000202@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" Hi Jiang, On 03/03/2013 11:43 PM, Jiang Liu wrote: > Hi Simon, > Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel > can't directly access highmem pages. Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. > Regards! > Gerry > > On 02/28/2013 02:13 PM, Simon Jeons wrote: >> Hi Jiang, >> >> https://patchwork.kernel.org/patch/1781291/ >> >> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx197.postini.com [74.125.245.197]) by kanga.kvack.org (Postfix) with SMTP id 58EF86B0002 for ; Mon, 4 Mar 2013 11:37:22 -0500 (EST) Received: by mail-pb0-f54.google.com with SMTP id rr4so3188622pbb.13 for ; Mon, 04 Mar 2013 08:37:21 -0800 (PST) Message-ID: <5134CDBB.60700@gmail.com> Date: Tue, 05 Mar 2013 00:37:15 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> In-Reply-To: <5133E356.6000502@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/04/2013 07:57 AM, Simon Jeons wrote: > > Hi Jiang, > On 03/03/2013 11:43 PM, Jiang Liu wrote: >> Hi Simon, >> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >> can't directly access highmem pages. > > Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. Hi Simon, According to my understanding, bootmem allocator does only manages lowmem pages. For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take x86 as an example: 1) following code set memblock.current_limit to max_low_pfn. arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), which has following code to avoid allocate highmem pages: static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, u64 goal, u64 limit) { void *ptr; u64 addr; if (limit > memblock.current_limit) limit = memblock.current_limit; addr = memblock_find_in_range_node(goal, limit, size, align, nid); if (!addr) return NULL; } I guess it's the same for other architectures. On the other hand, some other architectures may allocate highmem pages during boot by directly using memblock interfaces. For example, ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. I'm working a patch set to fix those cases. Regards! Gerry > >> Regards! >> Gerry >> >> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>> Hi Jiang, >>> >>> https://patchwork.kernel.org/patch/1781291/ >>> >>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx134.postini.com [74.125.245.134]) by kanga.kvack.org (Postfix) with SMTP id 2C8856B0002 for ; Tue, 5 Mar 2013 07:19:25 -0500 (EST) Received: by mail-ie0-f171.google.com with SMTP id 10so7638168ied.2 for ; Tue, 05 Mar 2013 04:19:24 -0800 (PST) Message-ID: <5135E2C7.8050105@gmail.com> Date: Tue, 05 Mar 2013 20:19:19 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> In-Reply-To: <5134CDBB.60700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/05/2013 12:37 AM, Jiang Liu wrote: > On 03/04/2013 07:57 AM, Simon Jeons wrote: >> Hi Jiang, >> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>> Hi Simon, >>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>> can't directly access highmem pages. >> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. > Hi Simon, Hi Jiang, The comments of max_pfn_mapped is "highest direct mapped pfn over 4GB", so if both bootmem allocator and memblock just manage direct mapping pages? BTW, could you show me where you can figure out traditional bootmem allocator manages directly mapping pages? > According to my understanding, bootmem allocator does only manages lowmem pages. > For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. > For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take > x86 as an example: > 1) following code set memblock.current_limit to max_low_pfn. > arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); > 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), > which has following code to avoid allocate highmem pages: > static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, > u64 goal, u64 limit) > { > void *ptr; > u64 addr; > > if (limit > memblock.current_limit) > limit = memblock.current_limit; > > addr = memblock_find_in_range_node(goal, limit, size, align, nid); > if (!addr) > return NULL; > } > > I guess it's the same for other architectures. On the other hand, some other architectures > may allocate highmem pages during boot by directly using memblock interfaces. For example, > ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. > > I'm working a patch set to fix those cases. > > Regards! > Gerry > > >>> Regards! >>> Gerry >>> >>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>> Hi Jiang, >>>> >>>> https://patchwork.kernel.org/patch/1781291/ >>>> >>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx121.postini.com [74.125.245.121]) by kanga.kvack.org (Postfix) with SMTP id F34E76B0002 for ; Tue, 5 Mar 2013 07:21:20 -0500 (EST) Received: by mail-ie0-f176.google.com with SMTP id k13so7611317iea.21 for ; Tue, 05 Mar 2013 04:21:20 -0800 (PST) Message-ID: <5135E33C.1030708@gmail.com> Date: Tue, 05 Mar 2013 20:21:16 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> In-Reply-To: <5134CDBB.60700@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/05/2013 12:37 AM, Jiang Liu wrote: > On 03/04/2013 07:57 AM, Simon Jeons wrote: >> Hi Jiang, >> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>> Hi Simon, >>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>> can't directly access highmem pages. >> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. > Hi Simon, > According to my understanding, bootmem allocator does only manages lowmem pages. > For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. > For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take > x86 as an example: > 1) following code set memblock.current_limit to max_low_pfn. > arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); > 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), > which has following code to avoid allocate highmem pages: > static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, > u64 goal, u64 limit) > { > void *ptr; > u64 addr; > > if (limit > memblock.current_limit) > limit = memblock.current_limit; > > addr = memblock_find_in_range_node(goal, limit, size, align, nid); > if (!addr) > return NULL; > } > > I guess it's the same for other architectures. On the other hand, some other architectures > may allocate highmem pages during boot by directly using memblock interfaces. For example, > ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. highmem is just used for x86, correct? ppc doesn't have highmem I think. > > I'm working a patch set to fix those cases. > > Regards! > Gerry > > >>> Regards! >>> Gerry >>> >>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>> Hi Jiang, >>>> >>>> https://patchwork.kernel.org/patch/1781291/ >>>> >>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx164.postini.com [74.125.245.164]) by kanga.kvack.org (Postfix) with SMTP id 97A106B003B for ; Tue, 5 Mar 2013 10:03:28 -0500 (EST) Received: by mail-pb0-f43.google.com with SMTP id md12so4594490pbc.16 for ; Tue, 05 Mar 2013 07:03:27 -0800 (PST) Message-ID: <51360939.20306@gmail.com> Date: Tue, 05 Mar 2013 23:03:21 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> <5135E33C.1030708@gmail.com> In-Reply-To: <5135E33C.1030708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/05/2013 08:21 PM, Simon Jeons wrote: > On 03/05/2013 12:37 AM, Jiang Liu wrote: >> On 03/04/2013 07:57 AM, Simon Jeons wrote: >>> Hi Jiang, >>> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>>> Hi Simon, >>>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>>> can't directly access highmem pages. >>> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. >> Hi Simon, >> According to my understanding, bootmem allocator does only manages lowmem pages. >> For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. >> For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take >> x86 as an example: >> 1) following code set memblock.current_limit to max_low_pfn. >> arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); >> 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), >> which has following code to avoid allocate highmem pages: >> static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, >> u64 goal, u64 limit) >> { >> void *ptr; >> u64 addr; >> >> if (limit > memblock.current_limit) >> limit = memblock.current_limit; >> >> addr = memblock_find_in_range_node(goal, limit, size, align, nid); >> if (!addr) >> return NULL; >> } >> >> I guess it's the same for other architectures. On the other hand, some other architectures >> may allocate highmem pages during boot by directly using memblock interfaces. For example, >> ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. > > highmem is just used for x86, correct? ppc doesn't have highmem I think. Hi Simon, Basically any 32 bit architectures may have the requirement to support highmem if it could support more than 1GB physical memory. For example, x86, arm, ppc, mips support highmem. Regards! Gerry > >> >> I'm working a patch set to fix those cases. >> >> Regards! >> Gerry >> >> >>>> Regards! >>>> Gerry >>>> >>>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>>> Hi Jiang, >>>>> >>>>> https://patchwork.kernel.org/patch/1781291/ >>>>> >>>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>>> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx153.postini.com [74.125.245.153]) by kanga.kvack.org (Postfix) with SMTP id 1AF7E6B0071 for ; Tue, 5 Mar 2013 10:09:04 -0500 (EST) Received: by mail-pb0-f54.google.com with SMTP id rr4so4554139pbb.27 for ; Tue, 05 Mar 2013 07:09:03 -0800 (PST) Message-ID: <51360A87.40008@gmail.com> Date: Tue, 05 Mar 2013 23:08:55 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> <5135E2C7.8050105@gmail.com> In-Reply-To: <5135E2C7.8050105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/05/2013 08:19 PM, Simon Jeons wrote: > On 03/05/2013 12:37 AM, Jiang Liu wrote: >> On 03/04/2013 07:57 AM, Simon Jeons wrote: >>> Hi Jiang, >>> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>>> Hi Simon, >>>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>>> can't directly access highmem pages. >>> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. >> Hi Simon, > > Hi Jiang, > > The comments of max_pfn_mapped is "highest direct mapped pfn over 4GB", so if both bootmem allocator and memblock just manage direct mapping pages? > BTW, could you show me where you can figure out traditional bootmem allocator manages directly mapping pages? Hi Simon, Bootmem allocator only manages directly mapped pages, but memblock could manage all pages. For traditional bootmem allocator, you could trace back callers of init_bootmem_node() and init_bootmem() to get the idea. Regards! Gerry > >> According to my understanding, bootmem allocator does only manages lowmem pages. >> For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. >> For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take >> x86 as an example: >> 1) following code set memblock.current_limit to max_low_pfn. >> arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); >> 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), >> which has following code to avoid allocate highmem pages: >> static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, >> u64 goal, u64 limit) >> { >> void *ptr; >> u64 addr; >> >> if (limit > memblock.current_limit) >> limit = memblock.current_limit; >> >> addr = memblock_find_in_range_node(goal, limit, size, align, nid); >> if (!addr) >> return NULL; >> } >> >> I guess it's the same for other architectures. On the other hand, some other architectures >> may allocate highmem pages during boot by directly using memblock interfaces. For example, >> ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. >> >> I'm working a patch set to fix those cases. >> >> Regards! >> Gerry >> >> >>>> Regards! >>>> Gerry >>>> >>>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>>> Hi Jiang, >>>>> >>>>> https://patchwork.kernel.org/patch/1781291/ >>>>> >>>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>>> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx171.postini.com [74.125.245.171]) by kanga.kvack.org (Postfix) with SMTP id 814B16B0005 for ; Tue, 5 Mar 2013 19:21:26 -0500 (EST) Received: by mail-oa0-f41.google.com with SMTP id i10so11987077oag.14 for ; Tue, 05 Mar 2013 16:21:25 -0800 (PST) Message-ID: <51368C01.2090608@gmail.com> Date: Wed, 06 Mar 2013 08:21:21 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> <5135E2C7.8050105@gmail.com> <51360A87.40008@gmail.com> In-Reply-To: <51360A87.40008@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 03/05/2013 11:08 PM, Jiang Liu wrote: > On 03/05/2013 08:19 PM, Simon Jeons wrote: >> On 03/05/2013 12:37 AM, Jiang Liu wrote: >>> On 03/04/2013 07:57 AM, Simon Jeons wrote: >>>> Hi Jiang, >>>> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>>>> Hi Simon, >>>>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>>>> can't directly access highmem pages. >>>> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. >>> Hi Simon, >> Hi Jiang, >> >> The comments of max_pfn_mapped is "highest direct mapped pfn over 4GB", so if both bootmem allocator and memblock just manage direct mapping pages? >> BTW, could you show me where you can figure out traditional bootmem allocator manages directly mapping pages? > Hi Simon, > Bootmem allocator only manages directly mapped pages, but memblock could manage all pages. > For traditional bootmem allocator, you could trace back callers of init_bootmem_node() and init_bootmem() > to get the idea. Hi Jiang, I track the callset of init_bootmem() against openrisc architecture(arch/openrisc/kernel/setup.c), it seems that it manages all the memory instead of low memory you mentioned. BTW, I didn't read x86_64 direct mapping codes before, if has enough big memory, what's the range of direct mapping? > Regards! > Gerry > >>> According to my understanding, bootmem allocator does only manages lowmem pages. >>> For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. >>> For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take >>> x86 as an example: >>> 1) following code set memblock.current_limit to max_low_pfn. >>> arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); >>> 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), >>> which has following code to avoid allocate highmem pages: >>> static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, >>> u64 goal, u64 limit) >>> { >>> void *ptr; >>> u64 addr; >>> >>> if (limit > memblock.current_limit) >>> limit = memblock.current_limit; >>> >>> addr = memblock_find_in_range_node(goal, limit, size, align, nid); >>> if (!addr) >>> return NULL; >>> } >>> >>> I guess it's the same for other architectures. On the other hand, some other architectures >>> may allocate highmem pages during boot by directly using memblock interfaces. For example, >>> ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. >>> >>> I'm working a patch set to fix those cases. >>> >>> Regards! >>> Gerry >>> >>> >>>>> Regards! >>>>> Gerry >>>>> >>>>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>>>> Hi Jiang, >>>>>> >>>>>> https://patchwork.kernel.org/patch/1781291/ >>>>>> >>>>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>>>> -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx185.postini.com [74.125.245.185]) by kanga.kvack.org (Postfix) with SMTP id 96BD96B0006 for ; Thu, 7 Mar 2013 21:14:28 -0500 (EST) Received: by mail-ie0-f174.google.com with SMTP id k10so1435305iea.5 for ; Thu, 07 Mar 2013 18:14:27 -0800 (PST) Message-ID: <5139497F.8010505@gmail.com> Date: Fri, 08 Mar 2013 10:14:23 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> <5135E2C7.8050105@gmail.com> <51360A87.40008@gmail.com> <51368C01.2090608@gmail.com> In-Reply-To: <51368C01.2090608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jiang Liu Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" Ping, :-) On 03/06/2013 08:21 AM, Simon Jeons wrote: > On 03/05/2013 11:08 PM, Jiang Liu wrote: >> On 03/05/2013 08:19 PM, Simon Jeons wrote: >>> On 03/05/2013 12:37 AM, Jiang Liu wrote: >>>> On 03/04/2013 07:57 AM, Simon Jeons wrote: >>>>> Hi Jiang, >>>>> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>>>>> Hi Simon, >>>>>> Bootmem allocator is used to managed DMA and Normal memory >>>>>> only, and it does not manage highmem pages because kernel >>>>>> can't directly access highmem pages. >>>>> Why you say so? Could you point out where you figure out bootmem >>>>> allocator doesn't handle highmem pages? In my understanding, it >>>>> doesn't distinguish low memory or high memory. >>>> Hi Simon, >>> Hi Jiang, >>> >>> The comments of max_pfn_mapped is "highest direct mapped pfn over >>> 4GB", so if both bootmem allocator and memblock just manage direct >>> mapping pages? >>> BTW, could you show me where you can figure out traditional bootmem >>> allocator manages directly mapping pages? >> Hi Simon, >> Bootmem allocator only manages directly mapped pages, but >> memblock could manage all pages. >> For traditional bootmem allocator, you could trace back callers of >> init_bootmem_node() and init_bootmem() >> to get the idea. > > Hi Jiang, > > I track the callset of init_bootmem() against openrisc > architecture(arch/openrisc/kernel/setup.c), it seems that it manages > all the memory instead of low memory you mentioned. BTW, I didn't read > x86_64 direct mapping codes before, if has enough big memory, what's > the range of direct mapping? > >> Regards! >> Gerry >> >>>> According to my understanding, bootmem allocator does only >>>> manages lowmem pages. >>>> For traditional bootmem allocator in mm/bootmem.c, it could only >>>> manages directly mapped lowmem pages. >>>> For new bootmem allocator in mm/nobootmem.c, it depends on memblock >>>> to do the real work. Let's take >>>> x86 as an example: >>>> 1) following code set memblock.current_limit to max_low_pfn. >>>> arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); >>>> 2) the core of bootmem allocator in nobootmem.c is function >>>> __alloc_memory_core_early(), >>>> which has following code to avoid allocate highmem pages: >>>> static void * __init __alloc_memory_core_early(int nid, u64 size, >>>> u64 align, >>>> u64 goal, u64 limit) >>>> { >>>> void *ptr; >>>> u64 addr; >>>> >>>> if (limit > memblock.current_limit) >>>> limit = memblock.current_limit; >>>> >>>> addr = memblock_find_in_range_node(goal, limit, size, >>>> align, nid); >>>> if (!addr) >>>> return NULL; >>>> } >>>> >>>> I guess it's the same for other architectures. On the other hand, >>>> some other architectures >>>> may allocate highmem pages during boot by directly using memblock >>>> interfaces. For example, >>>> ppc use memblock interfaces to allocate highmem pages for giagant >>>> hugetlb pages. >>>> >>>> I'm working a patch set to fix those cases. >>>> >>>> Regards! >>>> Gerry >>>> >>>> >>>>>> Regards! >>>>>> Gerry >>>>>> >>>>>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>>>>> Hi Jiang, >>>>>>> >>>>>>> https://patchwork.kernel.org/patch/1781291/ >>>>>>> >>>>>>> You said that the bootmem allocator doesn't touch *highmem >>>>>>> pages*, so highmem zones' managed_pages is set to the accurate >>>>>>> value "spanned_pages - absent_pages" in function >>>>>>> free_area_init_core() and won't be updated anymore. Why it >>>>>>> doesn't touch *highmem pages*? Could you point out where you >>>>>>> figure out this? >>>>>>> > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx132.postini.com [74.125.245.132]) by kanga.kvack.org (Postfix) with SMTP id 570516B0006 for ; Thu, 7 Mar 2013 22:11:15 -0500 (EST) Message-ID: <513956C9.5020304@huawei.com> Date: Fri, 8 Mar 2013 11:11:05 +0800 From: Jiang Liu MIME-Version: 1.0 Subject: Re: mm: introduce new field "managed_pages" to struct zone References: <512EF580.6000608@gmail.com> <51336FB4.9000202@gmail.com> <5133E356.6000502@gmail.com> <5134CDBB.60700@gmail.com> <5135E2C7.8050105@gmail.com> <51360A87.40008@gmail.com> <51368C01.2090608@gmail.com> In-Reply-To: <51368C01.2090608@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Jiang Liu , "linux-mm@kvack.org >> Linux Memory Management List" On 2013-3-6 8:21, Simon Jeons wrote: > On 03/05/2013 11:08 PM, Jiang Liu wrote: >> On 03/05/2013 08:19 PM, Simon Jeons wrote: >>> On 03/05/2013 12:37 AM, Jiang Liu wrote: >>>> On 03/04/2013 07:57 AM, Simon Jeons wrote: >>>>> Hi Jiang, >>>>> On 03/03/2013 11:43 PM, Jiang Liu wrote: >>>>>> Hi Simon, >>>>>> Bootmem allocator is used to managed DMA and Normal memory only, and it does not manage highmem pages because kernel >>>>>> can't directly access highmem pages. >>>>> Why you say so? Could you point out where you figure out bootmem allocator doesn't handle highmem pages? In my understanding, it doesn't distinguish low memory or high memory. >>>> Hi Simon, >>> Hi Jiang, >>> >>> The comments of max_pfn_mapped is "highest direct mapped pfn over 4GB", so if both bootmem allocator and memblock just manage direct mapping pages? >>> BTW, could you show me where you can figure out traditional bootmem allocator manages directly mapping pages? >> Hi Simon, >> Bootmem allocator only manages directly mapped pages, but memblock could manage all pages. >> For traditional bootmem allocator, you could trace back callers of init_bootmem_node() and init_bootmem() >> to get the idea. > > Hi Jiang, > > I track the callset of init_bootmem() against openrisc architecture(arch/openrisc/kernel/setup.c), it seems that it manages all the memory instead of low memory you mentioned. BTW, I didn't read x86_64 direct mapping codes before, if has enough big memory, what's the range of direct mapping? Hi Simon, You need to find callset on 32 bit architectures because only 32bit architectures use highmem. 64-bits architectures have enough virtual space to directly map all physical memory, so they don't need highmem. Please take a look at arch/sparc/mm/init_32.c arch/m32r/kernel/setup.c arch/arm/mm/init.c Regards! Gerry > >> Regards! >> Gerry >> >>>> According to my understanding, bootmem allocator does only manages lowmem pages. >>>> For traditional bootmem allocator in mm/bootmem.c, it could only manages directly mapped lowmem pages. >>>> For new bootmem allocator in mm/nobootmem.c, it depends on memblock to do the real work. Let's take >>>> x86 as an example: >>>> 1) following code set memblock.current_limit to max_low_pfn. >>>> arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped(); >>>> 2) the core of bootmem allocator in nobootmem.c is function __alloc_memory_core_early(), >>>> which has following code to avoid allocate highmem pages: >>>> static void * __init __alloc_memory_core_early(int nid, u64 size, u64 align, >>>> u64 goal, u64 limit) >>>> { >>>> void *ptr; >>>> u64 addr; >>>> >>>> if (limit > memblock.current_limit) >>>> limit = memblock.current_limit; >>>> >>>> addr = memblock_find_in_range_node(goal, limit, size, align, nid); >>>> if (!addr) >>>> return NULL; >>>> } >>>> >>>> I guess it's the same for other architectures. On the other hand, some other architectures >>>> may allocate highmem pages during boot by directly using memblock interfaces. For example, >>>> ppc use memblock interfaces to allocate highmem pages for giagant hugetlb pages. >>>> >>>> I'm working a patch set to fix those cases. >>>> >>>> Regards! >>>> Gerry >>>> >>>> >>>>>> Regards! >>>>>> Gerry >>>>>> >>>>>> On 02/28/2013 02:13 PM, Simon Jeons wrote: >>>>>>> Hi Jiang, >>>>>>> >>>>>>> https://patchwork.kernel.org/patch/1781291/ >>>>>>> >>>>>>> You said that the bootmem allocator doesn't touch *highmem pages*, so highmem zones' managed_pages is set to the accurate value "spanned_pages - absent_pages" in function free_area_init_core() and won't be updated anymore. Why it doesn't touch *highmem pages*? Could you point out where you figure out this? >>>>>>> > > > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org