mm: introduce new field "managed_pages" to struct zone

mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

[-- Attachment #1: Type: text/plain, Size: 368 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 725 bytes --]

Re: mm: introduce new field "managed_pages" to struct zone

[Ric Mason]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

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. :(

[-- Attachment #2: Type: text/html, Size: 1143 bytes --]

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Simon Jeons]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: mm: introduce new field "managed_pages" to struct zone

[Jiang Liu]

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>