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=-2.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, 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 2B324C433DF for ; Sun, 28 Jun 2020 03:27:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A79E7207E8 for ; Sun, 28 Jun 2020 03:27:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="EoBiJJOy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A79E7207E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 090216B0003; Sat, 27 Jun 2020 23:27:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 040516B0005; Sat, 27 Jun 2020 23:27:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E71476B0006; Sat, 27 Jun 2020 23:27:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id CBB3D6B0003 for ; Sat, 27 Jun 2020 23:27:45 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3F785181AC9CB for ; Sun, 28 Jun 2020 03:27:45 +0000 (UTC) X-FDA: 76977186090.03.glue48_420cc0426e63 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 1879228A4EB for ; Sun, 28 Jun 2020 03:27:45 +0000 (UTC) X-HE-Tag: glue48_420cc0426e63 X-Filterd-Recvd-Size: 5429 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Sun, 28 Jun 2020 03:27:44 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id 35so5778291ple.0 for ; Sat, 27 Jun 2020 20:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=HdAo3Mw7Kuf1D8X0gP3KwpfjrxuXrckftUDhFmRdmhU=; b=EoBiJJOyKCp2MD2d5dIF0/gHMYU+ONVYo4gsOnyp47n1vyUTl5heKLe8J8iWch0v01 vhpT0mdhTntODdrTBAp1STfxhcwR4NzgRFREvdsNdlxmL52g+HzrYiaHY7RxrTKk3tpE qOVD2Pyxg+mUsAuTaVrVmQVoWvKuonnvhOLP50nrxXIT3R4dMfzsl6tdik6FjzcjBvkl 7hU6xx7YPcPixZcYXZKL+kDuywk1qyCpNSsXIFx9Pe2guaCXbddF9GLvxprop4GuILWf lwDDB+AWPHmgKC11ePMiEz1nvQc6RTDs8bD5dT/jIAR2DZ53ZjDBlQecKkMqMRfW9RC1 pwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=HdAo3Mw7Kuf1D8X0gP3KwpfjrxuXrckftUDhFmRdmhU=; b=G/2w5oAIRlv5V5+UYfWEvwq04tA52csLtT40KJEdXP82y88+9jX+9Hgon24HOGqMsj KFsxR4e50A0WXUWsooXifTw/OzRa0OJbjCVmLIwGSZSn+RgL8/KEf3QIzO0TM3HSB8Vf YWSQ1oJ7bsV/urkD2HOraMId+uTOEyz2MWDANNLaWqBJj/h7fGDdzgNYBaA763TfqEMB HJiYDdDEghq6m0VitZiXpmsooBA6EE7FyjgP3Rvc9JNiiZsXLPQWKYpU3Y1tCdoMW2hI hCxrqQ9Rnnx2A/+rmE2637LkKDtdgP8XuUQmFagZxuu5SgI8BDGB61E2QpuuodLUOBv7 kZoA== X-Gm-Message-State: AOAM530oWCHgY91E5HFB0aLEhbTT/XXvNaiEUo6hlzqsDqnfD8onw++a PCeKKIkes5r1qkNfYGpRejdwyQ== X-Google-Smtp-Source: ABdhPJwECnOY+Z4j9TFTnp9WV78NNkNXFncDDhPcPVoaz0zkTH2kPpPxJC0noc4sr9sIPL/odyZMUA== X-Received: by 2002:a17:90a:24ed:: with SMTP id i100mr6082731pje.22.1593314863362; Sat, 27 Jun 2020 20:27:43 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id o11sm6414281pjr.25.2020.06.27.20.27.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jun 2020 20:27:42 -0700 (PDT) Date: Sat, 27 Jun 2020 20:27:41 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: =?UTF-8?Q?=E5=AD=99=E4=B8=96=E9=BE=99_sunshilong?= cc: David Hildenbrand , linux-mm@kvack.org 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? In-Reply-To: Message-ID: References: <73b5db17-805a-4f1a-60f7-26695c0422e8@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1482994552-50353924-1593314862=:589812" X-Rspamd-Queue-Id: 1879228A4EB X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1482994552-50353924-1593314862=:589812 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > How can I understand it in the right way, especially for "from the same > pageblocks"? Could you please explain that in more detail? >=20 Movable page allocations (__GFP_MOVABLE) are first attempted from=20 MIGRATE_MOVABLE pageblocks; unmovable page allocations (~__GFP_MOVABLE)=20 are first attempted from MIGRATE_UNMOVABLE. That doesn't necessarily hel= p=20 if migration and compaction are disabled. __GFP_RECLAIMABLE (like dentries and inodes, for instance) have their own= =20 pageblocks, however: MIGRATE_RECLAIMABLE. If we can reclaim all memory=20 from these pageblocks, and it is all reclaimable (we didn't have to=20 allocate unmovable pages from it, for example), it should free up the=20 whole pageblock.=20 Other than that, the page allocator tries to grab the smallest free page=20 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? >=20 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? >=20 Movable memory can be allocated from ZONE_NORMAL on fallback. The revers= e=20 is not true: unmovable memory cannot be allocated from ZONE_MOVABLE. --1482994552-50353924-1593314862=:589812--