Hi David Hildenbrand：
>> Okay, but then I assume the target goal of your patch set is to minimize
>> CPU consumption/allocation stall time when allocating larger order pages.
>> Currently you state "the probablity of high-order-pages allocation would
>> be increased significantly", but I assume that's then not 100% correct.
>> What you measure is the stall time to allocate higher order pages, not
>> that you can allocate them.
You are right that multi_freearea is to to speed the rate of large-order-pages
allocation instead of increasing the probality of it if CONFIG_COMPACTION is
open.
>> Okay, again, this is then some optimization for allocation speed; which
>> makes it less attractive IMHO (at least for more invasive changes),
>> because I suspect this mostly helps in corner cases (Monkey benchmarks
>> corner cases AFAIU).
I really agree with the preciseness of the community that if we want to merge the
patch in baseline, we would do more test to proof that the patch will not degraded
to a degree that people care. But, maybe there are the detailed test-list for us to
test, or we really don't know how to proof there are no any side-effects on all situation
of memory-opt.
It is a question that has puzzled me for a long time.
>> 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.
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.
lipeifeng@xxxxxxxx
From: David HildenbrandDate: 2021-04-27 20:46To: lipeifeng@xxxxxxxx; Vlastimil Babka; peifengl55; schwidefsky; heiko.carstens; zhangshiming; zhouhuacai; guoweichao; guojianSubject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentationOn 26.04.21 12:19, lipeifeng@xxxxxxxx wrote:> Hi David Hildenbrand <mailto:david@xxxxxxxxxx>：>> >> And you don't mention what the baseline configuration was. For example,> >> how was compaction configured?> >> Just to clarify, what is monkey?> >> Monkey HTTP server? MonkeyTest disk benchmark? UI/Application Exerciser> >> Monkey?> -------------------------------------------------------------------------------------> I am sorry that i didn't give a clear explanation about Monkey.> It meant "UI/Application Exerciser Monkey" from google.>> Excuse me, let me introduce our test:>Thanks for more details on the test.> 1. record COMPACT_STALL> We tested the patch on linux-4.4/linux-4.9/linux-4.14/linux-4.19 and the> results shows that the patch is effective in reducing COMPACTSTALL.> - monkey for 12 hours.> - record COMPACTSTALL after test.>> Test-result: reduced COMPACTSTALL by 95.6% with the patch.> (the machine with 4 gigabytes of physical memery and in linux-4.19.)> ---------------------------------> | COMPACTSTALL> ---------------------------------> ori | 2189> ---------------------------------> optimization | 95> --------------------------------->> I fully agree with the value of compaction, but compaction also bring cpu> consumption and will increase the time of alloc_stall. So if we can let more> free high-orders-pages in buddy instead of signal pages, it will decrease> COMPACT_STALL and speed up memory allocation.Okay, but then I assume the target goal of your patch set is to minimizeCPU consumption/allocation stall time when allocating larger order pages.Currently you state "the probablity of high-order-pages allocation wouldbe increased significantly", but I assume that's then not 100% correct.What you measure is the stall time to allocate higher order pages, notthat you can allocate them.>> 2. record the speed of the high-orders-pages allocation(order=4 and> order = 8)> Before and after optimization, we tested the speed of the> high-orders-pages allocation> after 120-hours-Monkey in 10 Android mobile phones. and the result show that> the speed has been increased by more than 18%.>> Also, we do some test designed by us:> (the machine with 4 gigabytes of physical memery and in linux-4.19.)> model the usage of users, and constantly start and> operate the diffrent application for 120h, and we record COMPACT_STALL> is decreased by> 90+% and speed of the high-orders-pages is increaed by 15+%.Okay, again, this is then some optimization for allocation speed; whichmakes it less attractive IMHO (at least for more invasive changes),because I suspect this mostly helps in corner cases (Monkey benchmarkscorner cases AFAIU).>> and I have some question, i hope you can guide me if when you are free.> 1) What is the compaction configured?> Dost it meant the members in zone? like as follows:> unsigned int compact_considered;> unsigned int compact_defer_shift;> int compact_order_failed;> bool compact_blockskip_failed;> Or the some Macro variable? like as follows:> PAGE_ALLOC_COSTLY_ORDER = 3> MIN_COMPACT_PRIORITY = 1> MAX_COMPACT_RETRIES = 16>Rather if you have proactive compaction(/proc/sys/vm/compaction_proactiveness). But I assume because you'remessing with older kernels, that you didn't compare against that yet.Would be worth a comparison.>>> 1) multi freearea (which might> >> be problematic with sparcity)> 2) Can you pls tell me what is soarcity and what is the impact of this?> and whether there are some documents about it?Essentially CONFIG_SPARSEMEM, whereby we can have huge holes in physicalmemory layout and memory areas coming/going with memory hot(un)plug.Usually we manage all metadata per section. For example, pageblocks areallocated per section. We avoid arrays that depend on theinitial/maximum physical memory size.--Thanks,David / dhildenb
