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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 A56D1C433DF for ; Sun, 28 Jun 2020 05:15:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4362720782 for ; Sun, 28 Jun 2020 05:15:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cnP4VS0b" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4362720782 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 744866B0003; Sun, 28 Jun 2020 01:15:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F5646B0005; Sun, 28 Jun 2020 01:15:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E31A6B0006; Sun, 28 Jun 2020 01:15:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0004.hostedemail.com [216.40.44.4]) by kanga.kvack.org (Postfix) with ESMTP id 461E06B0003 for ; Sun, 28 Jun 2020 01:15:30 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D3E5B2C8B for ; Sun, 28 Jun 2020 05:15:29 +0000 (UTC) X-FDA: 76977457578.03.waste75_4f02f7126e64 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id A856E28A4EB for ; Sun, 28 Jun 2020 05:15:29 +0000 (UTC) X-HE-Tag: waste75_4f02f7126e64 X-Filterd-Recvd-Size: 5568 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sun, 28 Jun 2020 05:15:29 +0000 (UTC) Received: by mail-qk1-f176.google.com with SMTP id 145so10061209qke.9 for ; Sat, 27 Jun 2020 22:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PtvoyniNcmB177FkiTY3oE2lX+FcuuAGfpOe+HN1bpA=; b=cnP4VS0bi92WVaYQBQcxaYKc4csalrRKQBuvSpQsv3H/Q65VJUATygkr8AqQgWdDq2 YWodAsWvFtqdgf8j7YnmOqj9WAPge1zhXoQoUyZ2GCki4INhkZN4qWKL0gLXTGzjNc7l DvAM5nyAdkPysdHnWZXVjlJqXbZzrfvBRYGX+vW4LPnrsLlKZTnS11PZ3luDqehJrOIE d+2kKCY0C5iX1i506KKOCtkWLTb2mXNvzrFZP30/s7Xw7FyjNd1csgXk1RkrTpfwfXpB ynnsiS1hJsquhv93K9IBqopdLplNUAs0tN7HbcyW/VhU7qv566DtvfFcfZ+W84uZBDs1 eT6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PtvoyniNcmB177FkiTY3oE2lX+FcuuAGfpOe+HN1bpA=; b=f/kwxegX6W4WQpntXKtb24lqFMdJMffvVIVn0anI2RMa2F+A8JUcq3zyBGF+HM1/HR M2S1oipQalSzkggTh8Y6e4cuvZAim/eLVIVXDGMqYCBo5r6a6XVeVhpLpdHMYjjuuhWh U7KE/VRSJquaq4hPndPfQPatHP1vxlAK8SzNDavTRQtSgTUBGOFR5T+3ZgR3Sl5zwja0 BSRVwpEK2SRjsRPXkpOBn5zGMGf5ACzWheZlARViSJJtlVU/FhxW65Pq9paoDaq+BCPd VkE0mxj4wyekfJOfcDYMgf3dwiGlIDhfXKFRm8KgEYtraf3yppJnbLHBIx9ChFxVTGmv HqCA== X-Gm-Message-State: AOAM530VITxV6SV3hRQABZGF9DKSa2dhx40lhebY2XEKc1CNTEn98chY VIZeqN+hdo9blPIJqWUreec4v5hHgGYXvLggxRI= X-Google-Smtp-Source: ABdhPJxBDLZPAnaxK8GoBn8hmJXp8YZkf6DodUOlnCOY8Z39J3dvhUMcly1FDply5R1DSpDsS0sy/Hw9TqUVkRwZD84= X-Received: by 2002:a37:6886:: with SMTP id d128mr10141271qkc.12.1593321328629; Sat, 27 Jun 2020 22:15:28 -0700 (PDT) MIME-Version: 1.0 References: <73b5db17-805a-4f1a-60f7-26695c0422e8@redhat.com> In-Reply-To: From: =?UTF-8?B?5a2Z5LiW6b6ZIHN1bnNoaWxvbmc=?= Date: Sun, 28 Jun 2020 13:15:17 +0800 Message-ID: Subject: Re: Are there still some methods that could be used by the Linux kernel to reduce memory fragmentation while both CONFIG-MIGRATION and CONFIG-COMPACTION are disabled? To: David Rientjes Cc: David Hildenbrand , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A856E28A4EB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, David Rientjes Thank you for the clarification. My current understanding of this matter is at a different level with your help. >>Are there still some methods that could be used by the Linux kernel >> to reduce memory fragmentation? > >Without compaction or migration, that's just about it. Do you mean there are no other methods that could be used to achieve this goal? Thank you for your attention to this matter. Best Regards. sunshilong David Rientjes =E4=BA=8E2020=E5=B9=B46=E6=9C=8828=E6= =97=A5=E5=91=A8=E6=97=A5 =E4=B8=8A=E5=8D=8811:27=E5=86=99=E9=81=93=EF=BC=9A > > On Thu, 25 Jun 2020, =E5=AD=99=E4=B8=96=E9=BE=99 sunshilong wrote: > > > >Grouping pages by mobility simply means that we attempt (best > > >effort) to allocate unmovable pages from the same pageblocks and movab= le > > >pages from the same pageblocks. > > > > How can I understand it in the right way, especially for "from the same > > pageblocks"? Could you please explain that in more detail? > > > > Movable page allocations (__GFP_MOVABLE) are first attempted from > MIGRATE_MOVABLE pageblocks; unmovable page allocations (~__GFP_MOVABLE) > are first attempted from MIGRATE_UNMOVABLE. That doesn't necessarily hel= p > if migration and compaction are disabled. > > __GFP_RECLAIMABLE (like dentries and inodes, for instance) have their own > pageblocks, however: MIGRATE_RECLAIMABLE. If we can reclaim all memory > from these pageblocks, and it is all reclaimable (we didn't have to > allocate unmovable pages from it, for example), it should free up the > whole pageblock. > > Other than that, the page allocator tries to grab the smallest free page > when necessary to leave higher order pages available. > > > Are there still some methods that could be used by the Linux kernel > > to reduce memory fragmentation? > > > > Without compaction or migration, that's just about it. > > > I can draw the conclusion that ZONE_NORMAL is only used to allocate > > unmovable memory(i.e. no movable memory could be allocated from > > ZONE_NORMAL) while "kernelcore=3D (or movablecore=3D)" option is set. > > Am I right? > > > > Movable memory can be allocated from ZONE_NORMAL on fallback. The revers= e > is not true: unmovable memory cannot be allocated from ZONE_MOVABLE.