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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 0355DC433DF for ; Thu, 25 Jun 2020 03:22:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 796872078D for ; Thu, 25 Jun 2020 03:22:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="r8sJMYGv" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 796872078D 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 B2C166B0002; Wed, 24 Jun 2020 23:22:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8616B0003; Wed, 24 Jun 2020 23:22:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9553A6B0005; Wed, 24 Jun 2020 23:22:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0062.hostedemail.com [216.40.44.62]) by kanga.kvack.org (Postfix) with ESMTP id 7354C6B0002 for ; Wed, 24 Jun 2020 23:22:29 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1E6881EE6 for ; Thu, 25 Jun 2020 03:22:29 +0000 (UTC) X-FDA: 76966286418.06.lunch77_300387726e49 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id E75F710043A85 for ; Thu, 25 Jun 2020 03:22:28 +0000 (UTC) X-HE-Tag: lunch77_300387726e49 X-Filterd-Recvd-Size: 18441 Received: from mail-qk1-f196.google.com (mail-qk1-f196.google.com [209.85.222.196]) by imf07.hostedemail.com (Postfix) with ESMTP for ; Thu, 25 Jun 2020 03:22:28 +0000 (UTC) Received: by mail-qk1-f196.google.com with SMTP id 80so4078730qko.7 for ; Wed, 24 Jun 2020 20:22:28 -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; bh=ZAtANI7Y2coaaCWYNIjreK22H+A9CK2cMcqLAEUjFPc=; b=r8sJMYGv2mIFY5Gl8k5367OHSId73+k0O5WmlVUXo/xYTlJDCo2//cwPwFJ5mQM73H jmFA9reTBnO8zw2oldUf/8mZUio3efyULQd6fBp61r1nTOk7OPY6tdqLWPOexVMIDj4r V3fBNIq4pKj1hGL8MOxRxDd7f59qf4wfWbLRiLHttENb8yxfMo7102YMMRlcBbg4tn7W FsdAzvd6Jc8DmoJYc84WM629SXwAv2u1ihesWeUMMUdixO8P6KC2XNolGKlvuABLm7Bj 6EbVN2zuK/5IHaVspA6jAjYr0UQ2FsVgijjzyxKI2kid8kz/CjIIyNlcPh8OXYAr8rj/ haPQ== 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; bh=ZAtANI7Y2coaaCWYNIjreK22H+A9CK2cMcqLAEUjFPc=; b=jy4KCKwbymq4gF0nCrlspw5dkZFMqgzY1SdSeWLD0/iq/yQjFtejGCgJBpuvM7zouU g7h8vd6Opyv2Pj8x5XPiJT9TcmQKZUUcCYSJ2S6KWdA7G+/ww+LO94EuUg2Ll5NqMQAY bgJBeZVuo2WMYFk1g85VBus0Af0PUNI0X7paUmHfYkUbnj2/wQDCv+/n6bunuig8n2D7 U0+L1Sa9QAAQfPMNQBgInwdLkvQoTbVOJLvafTLw8Adftk3R5wi/FgLqlKkYI8QHX0FO kfICKHNzKxB+3TtT5Zh6dXWoKBdbECCwsV3TdPZjttt7PG7S8BFBsM2VCBtpRRiXbnLZ DyXA== X-Gm-Message-State: AOAM533p6EFSKX4MtHwsvefdSV8NURRPUPfjUgop9zN0GKHE+VPFaxNj /yfCEg4kSyidB/s9E9RaPG4TO92y6LHhiNrx84E= X-Google-Smtp-Source: ABdhPJxkouqU2wDLS+XlCZRZfTUdlmvuL9eSEsCUWIjyeVfbc3W0NN2qExgrR9WjucjhB4ab7gzVSYWDkCkzuZNzYSU= X-Received: by 2002:a37:6886:: with SMTP id d128mr18653302qkc.12.1593055347814; Wed, 24 Jun 2020 20:22:27 -0700 (PDT) MIME-Version: 1.0 References: <73b5db17-805a-4f1a-60f7-26695c0422e8@redhat.com> In-Reply-To: From: =?UTF-8?B?5a2Z5LiW6b6ZIHN1bnNoaWxvbmc=?= Date: Thu, 25 Jun 2020 11:22:16 +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: multipart/alternative; boundary="0000000000001d34f605a8e01a56" X-Rspamd-Queue-Id: E75F710043A85 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000140, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --0000000000001d34f605a8e01a56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,David Rientjes, David Hildenbrand Thanks a lot to both of you. >Grouping pages by mobility simply means that we attempt (best >effort) to allocate unmovable pages from the same pageblocks and movable >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? >Yes, you can use kernelcore=3D (or movablecore=3D) on the kernel command l= ine >to set this up: allocations from this zone must have __GFP_MOVABLE so >they "should" be migratable. This is typically only useful when >CONFIG_COMPACTION is enabled, however, to do that defragmentation work so >that higher order memory becomes available. I was very hopeful for this method(i.e. ZONE_MOVABLE). It's really bad news. As the subject, I have no choice other than disabling these options(i.e. CONFIG-MIGRATION and CONFIG-COMPACTION) since I am using a real-time OS(i.e. it needs a patch to the Linux kernel and some kconfig options should be disabled). Are there still some methods that could be used by the Linux kernel to reduce memory fragmentation? >> Is there some potential problems that I should be aware of if I enable >> "ZONE_MOVABLE" on real-time system? >> >Yes, if ZONE_MOVABLE is made too big then you can risk out of memory >kills: movable allocations can fallback to ZONE_NORMAL but unmovable >allocations cannot graduate to ZONE_MOVABLE. So if ZONE_NORMAL is full >(either because you have too much unmovable memory in-use or too much >movable fell back to ZONE_NORMAL), and you have more unmovable >allocations, you'll get reclaim in ZONE_NORMAL and, at worst case, oom >kills. 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? As the kernel without such option(i.e. kernelcore=3D or movablecore=3D), th= ere are both movable memory and unmovable memory in ZONE_NORMAL. For details, see the footnote. It's different with the option and without the option: Only unmovable memory could be allocated from ZONE_NORMAL while the option is set whereas both unmovable and movable could be allocated from it without setting the option. Am I right? Here is part of the output when executing "sudo cat /proc/pagetypeinfo" on the platform without the option(i.e. kernelcore=3D or movablecore=3D)=EF=BC=9A Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 DMA, type Unmovable 0 1 1 0 2 1 1 0 1 0 0 DMA, type Movable 0 0 0 0 0 0 0 0 0 1 3 DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 DMA32, type Unmovable 1 0 0 0 0 0 1 1 1 1 0 DMA32, type Movable 8 6 7 5 5 4 6 5 2 2 723 DMA32, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 DMA32, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 DMA32, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Normal, type Unmovable 0 23 9 2 1 1 0 1 10 11 0 Normal, type Movable 1 791 767 630 111 11 5 5 2 0 929 Normal, type Reclaimable 0 2 4 2 2 1 1 1 1 1 0 Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Movable Reclaimable HighAtomic Isolate Node 0, zone DMA 1 7 0 0 0 Node 0, zone DMA32 2 1526 0 0 0 Node 0, zone Normal 160 2318 74 0 0 Best regards. David Rientjes =E4=BA=8E2020=E5=B9=B46=E6=9C=8825=E6= =97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=881:22=E5=86=99=E9=81=93=EF=BC=9A > On Wed, 24 Jun 2020, =E5=AD=99=E4=B8=96=E9=BE=99 sunshilong wrote: > > > >> 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? > > > > > > > > >We do have mobility grouping on pageblock order. > > >Also, I think you can use ZONE_MOVABLE without migration and compactio= n, > > >to at least locally limit unmovable fragmentation. > > It's a good news. > > > > Could you please explain that in more detail for me or suggest some > documents > > for me to go through. > > > > /proc/buddyinfo and /proc/pagetypeinfo will show the various pageblocks o= n > the system. Grouping pages by mobility simply means that we attempt (bes= t > effort) to allocate unmovable pages from the same pageblocks and movable > pages from the same pageblocks. > > > As per the post( > http://lkml.iu.edu/hypermail/linux/kernel/1703.1/06782.html), > > I think it's something like ZONE_NORMAL. And I find that > > "ZONE_MOVEABLE" is available on Linux-v4.9. > > > > Yes, you can use kernelcore=3D (or movablecore=3D) on the kernel command = line > to set this up: allocations from this zone must have __GFP_MOVABLE so the= y > "should" be migratable. This is typically only useful when > CONFIG_COMPACTION is enabled, however, to do that defragmentation work so > that higher order memory becomes available. > > > Is there some potential problems that I should be aware of if I enable > > "ZONE_MOVABLE" on real-time system? > > > > Yes, if ZONE_MOVABLE is made too big then you can risk out of memory > kills: movable allocations can fallback to ZONE_NORMAL but unmovable > allocations cannot graduate to ZONE_MOVABLE. So if ZONE_NORMAL is full > (either because you have too much unmovable memory in-use or too much > movable fell back to ZONE_NORMAL), and you have more unmovable > allocations, you'll get reclaim in ZONE_NORMAL and, at worst case, oom > kills. --0000000000001d34f605a8e01a56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,David Rientjes, David Hildenbrand
Thanks a lot to b= oth of you.

>Grouping pages by mobility simply means that we atte= mpt (best
>effort) to allocate unmovable pages from the same pageblo= cks and movable
>pages from the same pageblocks.

How can I un= derstand it in the right way, especially for "from the same
pagebl= ocks"? Could you please explain that in more detail?

>Yes, y= ou can use kernelcore=3D (or movablecore=3D) on the kernel command line >to set this up: allocations from this zone must have __GFP_MOVABLE so =
>they "should" be migratable.=C2=A0 This is typically only= useful when
>CONFIG_COMPACTION is enabled, however, to do that defr= agmentation work so
>that higher order memory becomes available.
= I was very hopeful for this method(i.e. ZONE_MOVABLE).
It's really b= ad news. As the subject, I have no choice other than disabling=C2=A0
th= ese options(i.e. CONFIG-MIGRATION and CONFIG-COMPACTION)
since I am usin= g a real-time OS(i.e. it needs a patch to the Linux kernel
and some kcon= fig options should be disabled).

Are there still some methods that c= ould be used by the Linux kernel
to reduce memory fragmentation?
=C2= =A0

>> Is there some potential problems that I should be aware= of if I enable
>> "ZONE_MOVABLE" on real-time system?>>

>Yes, if ZONE_MOVABLE is made too big then you can ri= sk out of memory
>kills: movable allocations can fallback to ZONE_NO= RMAL but unmovable
>allocations cannot graduate to ZONE_MOVABLE.=C2= =A0 So if ZONE_NORMAL is full
>(either because you have too much unm= ovable memory in-use or too much
>movable fell back to ZONE_NORMAL),= and you have more unmovable
>allocations, you'll get reclaim in= ZONE_NORMAL and, at worst case, oom
>kills.
I can draw the concl= usion that ZONE_NORMAL is only used to allocate
unmovable memory(i.e. n= o movable memory could be allocated from
ZONE_NORMAL) while "kerne= lcore=3D (or movablecore=3D)" option is set.
Am I right?

As the kernel without such option(i.e. kernelcore=3D or movablecore=3D), t= here are=C2=A0
both movable memory and unmovable memory in ZONE_N= ORMAL.
For details, see the footnote.

It's different w= ith the option and without the option:
Only unmovable memory could be al= located from ZONE_NORMAL while the option
is set whereas both unmovable= and movable could be allocated from it without
setting the option.
= Am I right?


Here is part of the output when=C2=A0executing "= ;sudo cat /proc/pagetypeinfo" on the platform=C2=A0
without = the option(i.e. kernelcore=3D or movablecore=3D)=EF=BC=9A
Free pages cou= nt per migrate type at order =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A00 =C2=A0 1 =C2=A0 2 =C2=A0 3 =C2=A0 4 =C2=A0 5 =C2=A0 6 =C2=A0 7 =C2=A0 = 8 =C2=A0 9 =C2=A0 10
=C2=A0 =C2=A0DMA, type =C2=A0 =C2=A0Unmovable =C2= =A00 =C2=A0 1 =C2=A0 1 =C2=A0 0 =C2=A0 2 =C2=A0 1 =C2=A0 1 =C2=A0 0 =C2=A0 = 1 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0 =C2=A0DMA, type =C2=A0 =C2=A0 =C2=A0Mov= able =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0= =C2=A0 0 =C2=A0 1 =C2=A0 =C2=A03
=C2=A0 =C2=A0DMA, type =C2=A0Reclaimab= le =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 = =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0 =C2=A0DMA, type =C2=A0 HighAtomi= c =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 = =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0 =C2=A0DMA, type =C2=A0 =C2=A0 = =C2=A0Isolate =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0= =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0DMA32, type =C2=A0 =C2= =A0Unmovable =C2=A01 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 1 = =C2=A0 1 =C2=A0 1 =C2=A0 1 =C2=A0 =C2=A00
=C2=A0DMA32, type =C2=A0 =C2= =A0 =C2=A0Movable =C2=A08 =C2=A0 6 =C2=A0 7 =C2=A0 5 =C2=A0 5 =C2=A0 4 =C2= =A0 6 =C2=A0 5 =C2=A0 2 =C2=A0 2 =C2=A0723
=C2=A0DMA32, type =C2=A0Recla= imable =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0= 0 =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0DMA32, type =C2=A0 HighAtomic = =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2= =A0 0 =C2=A0 0 =C2=A0 =C2=A00
=C2=A0DMA32, type =C2=A0 =C2=A0 =C2=A0Isol= ate =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 = =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
Normal, type =C2=A0 =C2=A0Unmovable =C2= =A00 =C2=A023 =C2=A0 9 =C2=A0 2 =C2=A0 1 =C2=A0 1 =C2=A0 0 =C2=A0 1 =C2=A01= 0 =C2=A011 =C2=A0 =C2=A00
Normal, type =C2=A0 =C2=A0 =C2=A0Movable =C2= =A01 791 767 630 111 =C2=A011 =C2=A0 5 =C2=A0 5 =C2=A0 2 =C2=A0 0 =C2=A0929=
Normal, type =C2=A0Reclaimable =C2=A00 =C2=A0 2 =C2=A0 4 =C2=A0 2 =C2= =A0 2 =C2=A0 1 =C2=A0 1 =C2=A0 1 =C2=A0 1 =C2=A0 1 =C2=A0 =C2=A00
Normal= , type =C2=A0 HighAtomic =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0= 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00
Normal, type =C2= =A0 =C2=A0 =C2=A0Isolate =C2=A00 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0= 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 0 =C2=A0 =C2=A00

Number of bloc= ks type Unmovable Movable Reclaimable HighAtomic Isolate
Node 0, zone = =C2=A0 =C2=A0 =C2=A0DMA =C2=A0 =C2=A0 =C2=A0 =C2=A01 =C2=A0 =C2=A0 =C2=A0 7= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 = =C2=A0 =C2=A0 =C2=A0 0
Node 0, zone =C2=A0 =C2=A0DMA32 =C2=A0 =C2=A0 =C2= =A0 =C2=A02 =C2=A0 =C2=A01526 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 0
Node 0, zone =C2=A0 = Normal =C2=A0 =C2=A0 =C2=A0160 =C2=A0 =C2=A02318 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A074 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 0
=
Best regards.

David Rientjes <rientjes@google.com> =E4=BA=8E2020=E5=B9=B46=E6=9C=8825=E6= =97=A5=E5=91=A8=E5=9B=9B =E4=B8=8A=E5=8D=881:22=E5=86=99=E9=81=93=EF=BC=9A<= br>
On Wed, 24 Jun 2= 020, =E5=AD=99=E4=B8=96=E9=BE=99 sunshilong wrote:

> >> 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?
> >
> >
> >We do have mobility grouping on pageblock order.
> >Also, I think you can use ZONE_MOVABLE without migration and compa= ction,
> >to at least locally limit unmovable fragmentation.
> It's a good news.
>
> Could you please explain that in more detail for me or suggest some do= cuments
> for me to go through.
>

/proc/buddyinfo and /proc/pagetypeinfo will show the various pageblocks on =
the system.=C2=A0 Grouping pages by mobility simply means that we attempt (= best
effort) to allocate unmovable pages from the same pageblocks and movable pages from the same pageblocks.

> As per the post(http://lkml.iu.edu/h= ypermail/linux/kernel/1703.1/06782.html),
> I think it's something like ZONE_NORMAL. And I find that
> "ZONE_MOVEABLE" is available on Linux-v4.9.
>

Yes, you can use kernelcore=3D (or movablecore=3D) on the kernel command li= ne
to set this up: allocations from this zone must have __GFP_MOVABLE so they =
"should" be migratable.=C2=A0 This is typically only useful when =
CONFIG_COMPACTION is enabled, however, to do that defragmentation work so <= br> that higher order memory becomes available.

> Is there some potential problems that I should be aware of if I enable=
> "ZONE_MOVABLE" on real-time system?
>

Yes, if ZONE_MOVABLE is made too big then you can risk out of memory
kills: movable allocations can fallback to ZONE_NORMAL but unmovable
allocations cannot graduate to ZONE_MOVABLE.=C2=A0 So if ZONE_NORMAL is ful= l
(either because you have too much unmovable memory in-use or too much
movable fell back to ZONE_NORMAL), and you have more unmovable
allocations, you'll get reclaim in ZONE_NORMAL and, at worst case, oom =
kills.
--0000000000001d34f605a8e01a56--