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.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 A692DC433B4 for ; Thu, 22 Apr 2021 09:29:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EEF7D61422 for ; Thu, 22 Apr 2021 09:29:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEF7D61422 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1D1256B006C; Thu, 22 Apr 2021 05:29:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 15AFE6B006E; Thu, 22 Apr 2021 05:29:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EC7DA6B0070; Thu, 22 Apr 2021 05:29:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id CD1F66B006C for ; Thu, 22 Apr 2021 05:29:50 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 876164DB1 for ; Thu, 22 Apr 2021 09:29:50 +0000 (UTC) X-FDA: 78059480940.31.37F498C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 067DAA0003A2 for ; Thu, 22 Apr 2021 09:29:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619083789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0PIZShYvKtST+t3n52TdrMJm7SNB4Egh+W9Ps7RZpaU=; b=gcNleYAsEBXWjTAuzXIQeDCuRe23L+HIYleH7pQV2tunTqaI2MEUJzfJNi/7Xi7+522ZkO izXrBvdHEydm0LuTEnlLrovslqdzK/tXxihBL3PidHqSKsZR9IbdSBLObvW2/cCRwQ39y3 1c2DJ4VLd/fQHIqE40AAXzq06dSqamY= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-281-UjPX3m1TNgqkfapqrIbeDA-1; Thu, 22 Apr 2021 05:29:45 -0400 X-MC-Unique: UjPX3m1TNgqkfapqrIbeDA-1 Received: by mail-wr1-f71.google.com with SMTP id 93-20020adf80e60000b0290106fab45006so9023884wrl.20 for ; Thu, 22 Apr 2021 02:29:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=0PIZShYvKtST+t3n52TdrMJm7SNB4Egh+W9Ps7RZpaU=; b=e2ZLE/ILdLuDQCHhijz26Qs9T9Xdjbbe8fPnc/i8s8DVB2r1riJJ3Fx5QfDktS/JBd mBRLIwdLuiua7HPYKJ5E7gA9bscMsOy2zyYpgfaWwV3wXdYpVqHUeqCIbiCA9CXlaDHZ Z4/wJEuVx9H8nCiK3CYiId6tchD1eBHIjK6soCG8u4zLDv7Gzq7K3AAsxZrO78d6Q+cu t8PLVmUnErGhSDhO1BNru2q+IjPJ/5oNJ2wymu+5Qtt3O7nRNtefofWWjb9fCokiFZr7 QwkPKT8rb8Ob/JERX2ZL8ZSZohl2BhZlGJIHNWmuzY/cbQkvIstluREh5XHaSpWHuZ2x PxQw== X-Gm-Message-State: AOAM5310xVWhiS2EaK7OShnFYLr+VTERc0EF5Y2O2o+CCecSPJslc2a1 bINUULEc4QKXdVg+Hr8YL1YobNkXhJ51/RcRqDT3urdq18fcFsQQ2+WP2mSQPALM4g+yUc7rdpf HA9IiPqwSBfuXG334ZokYhJCRYSAIxylgzmOVdHVs3xdHkB7fg/qoGmxGjGo= X-Received: by 2002:adf:db4d:: with SMTP id f13mr2895411wrj.203.1619083784500; Thu, 22 Apr 2021 02:29:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwMIYAi4zF8uklRRuwtVpR5GrIUVC3QeT3/EA97BIzR0U3FMxPnuGUMv97lzDYt2bTPcpMmGw== X-Received: by 2002:adf:db4d:: with SMTP id f13mr2895377wrj.203.1619083784194; Thu, 22 Apr 2021 02:29:44 -0700 (PDT) Received: from [192.168.3.132] (p4ff23eb0.dip0.t-ipconnect.de. [79.242.62.176]) by smtp.gmail.com with ESMTPSA id f1sm2567569wru.60.2021.04.22.02.29.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Apr 2021 02:29:43 -0700 (PDT) To: Vlastimil Babka , 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: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation Message-ID: Date: Thu, 22 Apr 2021 11:29:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Queue-Id: 067DAA0003A2 X-Stat-Signature: wr1rcp7uwjwwfmfznteskihytskpqai6 X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf24; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619083780-435709 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 16.04.21 13:06, Vlastimil Babka wrote: > On 4/14/21 4:38 AM, lipeifeng@oppo.com wrote: >> From: lipeifeng >> >> This patch would "sort" the free-pages in buddy by pages-PFN to concen= trate >> 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 are= a of >> memory and the probablity of high-order-pages allocation would be incr= eased >> significantly. >> ----------------------------------------------------------------------= - >> >> 1) Divide memory into several segments by pages-PFN >> "Multi_freearea" would divide memory into FREE_AREA_COUNTS segme= nts >> 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) 0xFFF= FF(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 >=3D 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 =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. >> >> By this way,low-order pages will be concentrated in the front ar= ea >> of memory.Because of few memory-pollution in the back area of me= mory, >> the sussessful probablity of high-order allocation would be impr= oved. >> >> 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 | >=3D 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, t= he >> greater the probablity of merging that into high-order pages. >=20 > 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. >=20 Let's consider part 3 only and ignore the 1) multi freearea (which might=20 be problematic with sparcity) and 2) the modified allocation scheme=20 (which doesn't yet quite sense to me yet, e.g., because we group by=20 mobility and have compaction in place; I assume this really only helps=20 in some special cases -- like the test case you are giving; I might be=20 wrong) Right now, we decide whether to but to head or tail based on how likely=20 it is that we might merge to a higher-order page (buddy_merge_likely())=20 in the future. So we only consider the current "neighborhood" of the=20 page we're freeing. As we restrict our neighborhood to MAX_ORDER - 1=20 pages (what we can actually merge). Of course, we can easily be wrong=20 here. Grouping by movability and compaction only helps to some degree I=20 guess. AFAIK, what you propose is basing the decisions where to place a page=20 (in addition?) on a median_pfn. Without 1) and 2) I cannot completely=20 understand if 3) itself would help at all (and how to set the=20 median_pfn). But it would certainly be interesting if we can tweak the=20 current logic to better identify merge targets simply by tweaking=20 buddy_merge_likely() or the assumptions it is making. --=20 Thanks, David / dhildenb