From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4506AC433B4 for ; Fri, 16 Apr 2021 11:06:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C508561152 for ; Fri, 16 Apr 2021 11:06:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C508561152 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 48F8A6B006C; Fri, 16 Apr 2021 07:06:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43FDA6B0070; Fri, 16 Apr 2021 07:06:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E1886B0071; Fri, 16 Apr 2021 07:06:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0091.hostedemail.com [216.40.44.91]) by kanga.kvack.org (Postfix) with ESMTP id 105676B006C for ; Fri, 16 Apr 2021 07:06:52 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C231C1E0B for ; Fri, 16 Apr 2021 11:06:51 +0000 (UTC) X-FDA: 78037952622.30.8C7CE74 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf05.hostedemail.com (Postfix) with ESMTP id 7D408E00012F for ; Fri, 16 Apr 2021 11:06:50 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0C080ADE2; Fri, 16 Apr 2021 11:06:50 +0000 (UTC) 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 References: <20210414023803.937-1-lipeifeng@oppo.com> From: Vlastimil Babka Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation Message-ID: Date: Fri, 16 Apr 2021 13:06:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: <20210414023803.937-1-lipeifeng@oppo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Queue-Id: 7D408E00012F X-Stat-Signature: czwac1brp7bh4o6ncu8fik6as3di9mmx X-Rspamd-Server: rspam02 Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1618571210-374902 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000634, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/14/21 4:38 AM, lipeifeng@oppo.com wrote: > From: lipeifeng >=20 > This patch would "sort" the free-pages in buddy by pages-PFN to concent= rate > low-order-pages allocation in the front area of memory and high-order-p= ages > 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 incre= ased > significantly. > ----------------------------------------------------------------------- >=20 > 1) Divide memory into several segments by pages-PFN > "Multi_freearea" would divide memory into FREE_AREA_COUNTS segment= s > by pages-PFN,each memory-segment corresponds to a free_area. >=20 > 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][] >=20 > NOTE: Selecting the corresponding freearea when pages are freed ba= ck > 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) >=20 > By this way, all pages in the same segment/free_area is within a > certain range of pages-PFN. >=20 > 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 >=3D HIGH_ORDER_TO_FLC: > free_area[FREE_AREA_COUNTS - 1] -> ... -> free_area[0] >=20 > Example: > The machine(4G of physical memery) and FREE_AREA_COUNTS(4) > and HIGH_ORDER_TO_FLC(3). > If user allocs page(order =3D 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 =3D 4),it would take page from > free_area[3][] first, if that fails,try free_area[2][] and so on. >=20 > 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 memo= ry, > the sussessful probablity of high-order allocation would be improv= ed. >=20 > 3) Adjust the location of free-pages in the free_list > "Multi_freearea" would place free-pages in the head of free_list i= f > pages-PFN is smaller than free_area_segment[flc]->median_pfn and i= n > the tail of free_list on the contrary. >=20 > Example: > page-PFN: free_area_segment[flc]->median_pfn > | > free_list: page->page->page->...|...page->page->page > pages-PFN:| < median_pfn | >=3D median_pfn | >=20 > 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.