From: Vlastimil Babka <vbabka@suse.cz>
To: lipeifeng@oppo.com, peifengl55@gmail.com, schwidefsky@de.ibm.com,
heiko.carstens@de.ibm.com
Cc: linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation
Date: Fri, 16 Apr 2021 13:06:49 +0200 [thread overview]
Message-ID: <a7bb16c0-31b2-6aa5-2186-8c957955649e@suse.cz> (raw)
In-Reply-To: <20210414023803.937-1-lipeifeng@oppo.com>
On 4/14/21 4:38 AM, lipeifeng@oppo.com wrote:
> From: lipeifeng <lipeifeng@oppo.com>
>
> This patch would "sort" the free-pages in buddy by pages-PFN to concentrate
> low-order-pages allocation in the front area of memory and high-order-pages
> allcation on the contrary so that few memory-pollution in the back area of
> memory and the probablity of high-order-pages allocation would be increased
> significantly.
> -----------------------------------------------------------------------
>
> 1) Divide memory into several segments by pages-PFN
> "Multi_freearea" would divide memory into FREE_AREA_COUNTS segments
> by pages-PFN,each memory-segment corresponds to a free_area.
>
> Example: machine(4G of physical memery) and FREE_AREA_COUNTS(4):
> page-PFN:0x0 0x40000(1G) 0x80000(2G) 0xc0000(3G) 0xFFFFF(4G)
> |------------|--------------|--------------|-------------|
> free_area: [0][] [1][] [2][] [3][]
>
> NOTE: Selecting the corresponding freearea when pages are freed back
> to buddy:
> - pages-PFN[0, free_area_segment[0].max_pfn] -> free_area[0][]
> - pages-PFN[free_area_segment[flc - 1].max_pfn,
> free_area_segment[flc].max_pfn] -> free_area[flc][]
> (flc > 0)
>
> By this way, all pages in the same segment/free_area is within a
> certain range of pages-PFN.
>
> 2) Select the corresponding freearea to alloc-pages
> "Multi_freearea" would select the corresponding free_area by the
> allocation-order when alloc-pages.
> - order < HIGH_ORDER_TO_FLC:
> free_area[0] -> ... -> free_area[FREE_AREA_COUNTS - 1]
> - order >= HIGH_ORDER_TO_FLC:
> free_area[FREE_AREA_COUNTS - 1] -> ... -> free_area[0]
>
> Example:
> The machine(4G of physical memery) and FREE_AREA_COUNTS(4)
> and HIGH_ORDER_TO_FLC(3).
> If user allocs page(order = 0),it would take page from
> free_area[0][] first, if that fails,try free_area[1][] and so on.
> If user allocs page(order = 4),it would take page from
> free_area[3][] first, if that fails,try free_area[2][] and so on.
>
> By this way,low-order pages will be concentrated in the front area
> of memory.Because of few memory-pollution in the back area of memory,
> the sussessful probablity of high-order allocation would be improved.
>
> 3) Adjust the location of free-pages in the free_list
> "Multi_freearea" would place free-pages in the head of free_list if
> pages-PFN is smaller than free_area_segment[flc]->median_pfn and in
> the tail of free_list on the contrary.
>
> Example:
> page-PFN: free_area_segment[flc]->median_pfn
> |
> free_list: page->page->page->...|...page->page->page
> pages-PFN:| < median_pfn | >= median_pfn |
>
> Because it would take pages from the head of the freelist first in
> buddy system,the free-pages in the tail are more likely to keep in the
> buddy system.The closer the PFN of pages kept in buddy system, the
> greater the probablity of merging that into high-order pages.
I think this part 3) would be worth to be tried separately first, as it's not a
big change compared to the other ones.
next prev parent reply other threads:[~2021-04-16 11:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-14 2:38 lipeifeng
2021-04-16 11:06 ` Vlastimil Babka [this message]
2021-04-19 2:37 ` lipeifeng
2021-04-22 9:37 ` David Hildenbrand
2021-04-22 9:29 ` David Hildenbrand
2021-04-26 3:19 ` lipeifeng
2021-04-26 8:37 ` David Hildenbrand
2021-04-26 10:19 ` lipeifeng
2021-04-27 12:46 ` David Hildenbrand
2021-04-28 4:03 ` lipeifeng
2021-04-28 9:04 ` David Hildenbrand
2021-04-28 10:53 ` lipeifeng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a7bb16c0-31b2-6aa5-2186-8c957955649e@suse.cz \
--to=vbabka@suse.cz \
--cc=heiko.carstens@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=lipeifeng@oppo.com \
--cc=peifengl55@gmail.com \
--cc=schwidefsky@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox