[PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel

Kumar Gala galak at kernel.crashing.org
Thu Sep 27 22:37:15 EST 2012


On Sep 24, 2012, at 7:31 AM, Kumar Gala wrote:

> 
> On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
> 
>> 
>> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>> 
>>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>> 
>>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so
>>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>>> greater than the device's DMA capability and device uses
>>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>> 
>>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), so
>>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>>> __GFP_DMA &
>>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>>> total memory size. By doing this, devices which cannot DMA all the
>>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>>> all
>>>>> the memory will not be affected by this limitation.
>>>>>>> 
>>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie at freescale.com>
>>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu at freescale.com>
>>>>>>> Signed-off-by: Chen Yuanquan <B41889 at freescale.com>
>>>>>>> ---
>>>>>>> changes for v2:
>>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>> 
>>>>> 
>>>>> There must have been a misunderstanding. I think this should be a
>>>>> runtime choice, possibly by the platform code. Any reason that can't be
>>>> done ?
>>>>> 
>>>> [S.H] Do you mean this:
>>>> 
>>>> phys_addr_t platform_dma_size (maybe a default value should be used, then
>>>> platform code will change it)
>>>> 
>>>> if (top_of_ram > platform_dma_size)
>>>> 	max_zone_pfns[ZONE_DMA] = platform_dma_size >> PAGE_SHIFT; else
>>>> 	max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
>>>> 
>>>> max_zone_pfns[ZONE_NORMAL] = top_of_ram >> PAGE_SHIFT;
>>>> 
>>>>> Also how does Intel do it ?
>>>> [S.H] below are codes in Intel:
>>>> 
>>>> 403 void __init zone_sizes_init(void)
>>>> 404 {
>>>> 405         unsigned long max_zone_pfns[MAX_NR_ZONES];
>>>> 406
>>>> 407         memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>>> 408
>>>> 409 #ifdef CONFIG_ZONE_DMA
>>>> 410         max_zone_pfns[ZONE_DMA]         = MAX_DMA_PFN;
>>>> 411 #endif
>>>> 412 #ifdef CONFIG_ZONE_DMA32
>>>> 413         max_zone_pfns[ZONE_DMA32]       = MAX_DMA32_PFN;
>>>> 414 #endif
>>>> 415         max_zone_pfns[ZONE_NORMAL]      = max_low_pfn;
>>>> 416 #ifdef CONFIG_HIGHMEM
>>>> 417         max_zone_pfns[ZONE_HIGHMEM]     = max_pfn;
>>>> 418 #endif
>>>> 419
>>>> 
>>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three zones:
>>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>> 
>>> [S.H] Hello, Ben,
>>> 
>>> I have some questions, though I'm still expecting your comments.
>>> PPC does not have ZONE_DMA32 by default, if we want to use it, we need to add "config ZONE_DMA32" in Kconfig first.
>>> If setting multiple zones without ZONE_DMA, kmalloc in "include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>>> For the runtime choice in 64-bit kernel, what exactly multiple zones should be used?
>>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>>> Then what the size should be set for them respectively?
>>> 
>>> Please comment, Thanks!
>> 
>> I think Ben is saying that Kconfig would enable ZONE_DMA32 for all PPC64, but make it runtime/per platform how we setup the zone's such that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value as ZONE_DMA.
>> 
>> However that's just a guess.
> 
> Ben,
> 
> Can you help clarify your thoughts here.
> 
> thanks

Ben?

- k


More information about the Linuxppc-dev mailing list