Re: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation

["lipeifeng@oppo.com" <lipeifeng@oppo.com>]

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

Hi David Hildenbrand:

>> From your description only I cannot tell how that would really work.
>> Your description of 1) indicated that we are dealing with an array to
>> manage memory segments, and arrays are a bad data structure when it
>> comes to sparsity.

In the baseline, it also manage memory by array(zone->free_area) in linux, as follows:
struct zone {
......
    struct free_area free_area[MAX_ORDER];
}

"Multi_free_area" would devide physical memory into serveral parts in zone by page-PFN,
and it also uses free_area to manage each parts of memory:
struct zone {
......
    struct free_area free_area[flc][MAX_ORDER];  // flc def to 4
}

All the logic of memory-opt is unchange experts for that: select the corresponding freearea
to alloc-pages by allocation-order which is to concentrate most of low-order-pages(almost
signal-page) allocation in the front area of physical memory and few memory-pollution in the
back area of the memory. Theoretically,  there will not be too much risk i think. 

Because i am not a expert so that maybe there are some case i have not considered and maybe
there are something wrong displeaed you in my email, pls don't take it ill.


>> Just always keep in mind that upstream Linux has a very broad community.
>> What might be "good enough" for smartphones might not be well suited for
>> servers, VMs, embedded devices, other archs ... just imagine the RAM
>> size differences, sparse layout, dynamic memory changes, ...
 
>> Adding additional complexity to the buddy has to have a compelling
>> benefit; keep in mind that any complexity we introduce has to be
>> maintained in the long term.
 
>> Having that said, starting with small steps is IMHO the right approach.

I will make the patch-series and try to make the patch smaller and readable and
thanks your advices indeed.





lipeifeng@oppo.com
 
From: David Hildenbrand
Date: 2021-04-28 17:04
To: lipeifeng@oppo.com; Vlastimil Babka; peifengl55; schwidefsky; heiko.carstens; zhangshiming; zhouhuacai; guoweichao; guojian
CC: linux-s390; linux-kernel; linux-mm
Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation
>  >> Essentially CONFIG_SPARSEMEM, whereby we can have huge holes in physical
>  >> memory layout and memory areas coming/going with memory hot(un)plug.
>  >> Usually we manage all metadata per section. For example, pageblocks are
>  >> allocated per section. We avoid arrays that depend on the
>  >> initial/maximum physical memory size.
> 
> CONFIG_SPRSEMEM has been opened in some of our product with 
> Qcom-platform and
> MTK platform. AFAIK, multi_freearea would not bring problem to 
> it？because the patch
> just manage the physical memory of zone to serveral section(free_area) 
> and adjust the
> the range of pages-PFN for buddy-alloc-pages by the alloction-order. 
> With memory
> hot(un)plug, we would initialize the members of "multi_freearea" in zone.
 
From your description only I cannot tell how that would really work. 
Your description of 1) indicated that we are dealing with an array to 
manage memory segments, and arrays are a bad data structure when it 
comes to sparsity.
 
> 
> The patch has been merged in the baseline of our product that has been 
> sold all over the
> world with Linux-4.4/4.9/4.19 so that i don't think there will be too 
> much risk. Of course,
> i might be wrong.
 
Just always keep in mind that upstream Linux has a very broad community. 
What might be "good enough" for smartphones might not be well suited for 
servers, VMs, embedded devices, other archs ... just imagine the RAM 
size differences, sparse layout, dynamic memory changes, ...
 
Adding additional complexity to the buddy has to have a compelling 
benefit; keep in mind that any complexity we introduce has to be 
maintained in the long term.
 
Having that said, starting with small steps is IMHO the right approach.
 
-- 
Thanks,
 
David / dhildenb
 

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