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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 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 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.

--
Thanks,

David / dhildenb






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux