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 E63CBC433ED for ; Wed, 28 Apr 2021 09:04:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 409C361420 for ; Wed, 28 Apr 2021 09:04:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 409C361420 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 4FDD26B0036; Wed, 28 Apr 2021 05:04:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 486BE6B006E; Wed, 28 Apr 2021 05:04:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 301326B0070; Wed, 28 Apr 2021 05:04:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 0E2786B0036 for ; Wed, 28 Apr 2021 05:04:43 -0400 (EDT) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8EF20180AD806 for ; Wed, 28 Apr 2021 09:04:39 +0000 (UTC) X-FDA: 78081190278.19.73491BA Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf03.hostedemail.com (Postfix) with ESMTP id 63B58C0007ED for ; Wed, 28 Apr 2021 09:04:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619600678; 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=Zy/Tt/0rdk34PfJBg6ggCnjTL4icF91iTv6QpcHj3wY=; b=FTTP1+tDphGRKReR7h7duMj6r6aBJ5qhooEoWGwz0PzgzKEkBQtwHW5KZgdaVUlZ4IONvJ i+qQ8Rr1F74T66KQlB9ifk5tuDvfXYpxOSurVIp2I6Q8TqkdF8e4ghrMZtX/SOZ4TaQbNn vIdo1p/vYztw20g1CavFQ59ameO2iCo= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-289-olf_I0XKNGqa4vgofWsaTw-1; Wed, 28 Apr 2021 05:04:36 -0400 X-MC-Unique: olf_I0XKNGqa4vgofWsaTw-1 Received: by mail-wm1-f70.google.com with SMTP id g199-20020a1c9dd00000b02901355dd71edaso4869484wme.7 for ; Wed, 28 Apr 2021 02:04:36 -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=Zy/Tt/0rdk34PfJBg6ggCnjTL4icF91iTv6QpcHj3wY=; b=GGxMH7f+lKPopxbMyMnXrd5S0K0EkNSOoivWfeX83oLgTvMMVEtMkP5OVgELD7neJT TiNxWisvCV9272pgf2KDsbPtw7PXNB5Uli7fvs9tDTNkyPqwSUiYlahs8J8+YRzHMPEh GVG2EPR9QXLwO9dTJDFHED/GaN6cpq3KfLeXdRGHOKHe/CizrJkC7JVXDzeYgUwKUp7T 6UX+aFY9SNgRyPc3gsDUZVXpTXZaZJpiAtRshmVtST5qy7YPQLZWy+yDpWVba3tihlKE ZFdOOpLyLEPbKh1nFUuVru260UitImTtk/gkt3j1ZXJYO2WxLj1tBfE3VsypDEbKKR1y tCfg== X-Gm-Message-State: AOAM531MiIjtjN2uHgUA3yEAOSUKoKT9zNZiZS4uNeMQhAKHsgO25A2A Gi9yVWas+v38xIKk7lwBsmP61Pbpe38ziv4Wc4iKgkcCYlNCeeY3GiBth2T8tVNiwBFEtEiohbj GK/U3o0u/tNy3EThAiccW7mfuTwI0QN9+W1Y5O7uwQSjOdUtY1X7Oe7vbpJ8= X-Received: by 2002:a05:600c:20c:: with SMTP id 12mr3192322wmi.138.1619600675537; Wed, 28 Apr 2021 02:04:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxyHQN1kXxwPITyG57p5yBf6PwQPqB7SzwurYnctESLQPRWN6ybBTj8o2+iODN0NtgGzZQI8g== X-Received: by 2002:a05:600c:20c:: with SMTP id 12mr3192278wmi.138.1619600675202; Wed, 28 Apr 2021 02:04:35 -0700 (PDT) Received: from ?IPv6:2003:d8:2f38:2400:62f4:c5fa:ba13:ac32? (p200300d82f38240062f4c5faba13ac32.dip0.t-ipconnect.de. [2003:d8:2f38:2400:62f4:c5fa:ba13:ac32]) by smtp.gmail.com with ESMTPSA id f24sm5734617wmb.32.2021.04.28.02.04.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Apr 2021 02:04:34 -0700 (PDT) To: "lipeifeng@oppo.com" , Vlastimil Babka , peifengl55 , schwidefsky , "heiko.carstens" , zhangshiming , zhouhuacai , guoweichao , guojian Cc: linux-s390 , linux-kernel , linux-mm References: <20210414023803.937-1-lipeifeng@oppo.com> <2021042611194631963076@oppo.com> <7dcc87f5-9ae5-613a-0cf4-820334592b90@redhat.com> <20210426181947189100132@oppo.com> <9808e36a-9e4e-d1e2-da49-beb567681a8b@redhat.com> <2021042812031720737751@oppo.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [RFC] mm: support multi_freearea to the reduction of external fragmentation Message-ID: Date: Wed, 28 Apr 2021 11:04:34 +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: <2021042812031720737751@oppo.com> 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: 63B58C0007ED X-Stat-Signature: g311abhof99765spcxp6gwaswuycn7w3 X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf03; 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: 1619600673-557637 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: > >> Essentially CONFIG_SPARSEMEM, whereby we can have huge holes in phy= sical > >> 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. >=20 > CONFIG_SPRSEMEM has been opened in some of our product with=20 > Qcom-platform and > MTK platform. AFAIK, multi_freearea would not bring problem to=20 > it=EF=BC=9Fbecause the patch > just manage the physical memory of zone to serveral section(free_area)=20 > and adjust the > the range of pages-PFN for buddy-alloc-pages by the alloction-order.=20 > With memory > hot(un)plug, we would initialize the members of "multi_freearea" in zon= e. From your description only I cannot tell how that would really work.=20 Your description of 1) indicated that we are dealing with an array to=20 manage memory segments, and arrays are a bad data structure when it=20 comes to sparsity. >=20 > The patch has been merged in the baseline of our product that has been=20 > sold all over the > world with Linux-4.4/4.9/4.19 so that i don't think there will be too=20 > much risk. Of course, > i might be wrong. Just always keep in mind that upstream Linux has a very broad community.=20 What might be "good enough" for smartphones might not be well suited for=20 servers, VMs, embedded devices, other archs ... just imagine the RAM=20 size differences, sparse layout, dynamic memory changes, ... Adding additional complexity to the buddy has to have a compelling=20 benefit; keep in mind that any complexity we introduce has to be=20 maintained in the long term. Having that said, starting with small steps is IMHO the right approach. --=20 Thanks, David / dhildenb