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

David Hildenbrand
2021-04-27T12:46:12Z

On 26.04.21 12:19, lipeifeng@oppo.com wrote:
> Hi David Hildenbrand <mailto:david@redhat.com>：
>
> >> 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 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.

>
> 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; 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).

>
> 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're
messing 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 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.