From: David Rientjes <rientjes@google.com>
To: "孙世龙 sunshilong" <sunshilong369@gmail.com>
Cc: David Hildenbrand <david@redhat.com>, 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?
Date: Sat, 27 Jun 2020 20:27:41 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.22.394.2006272023080.589812@chino.kir.corp.google.com> (raw)
In-Reply-To: <CAAvDm6YzPcMyqGJ5dLDSBjWe-gnZMBo+aJTjfAsxQo1kY9dXtw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]
On Thu, 25 Jun 2020, 孙世龙 sunshilong wrote:
> >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?
>
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 help
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= (or movablecore=)" option is set.
> Am I right?
>
Movable memory can be allocated from ZONE_NORMAL on fallback. The reverse
is not true: unmovable memory cannot be allocated from ZONE_MOVABLE.
next prev parent reply other threads:[~2020-06-28 3:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-23 15:52 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? 孙世龙 sunshilong
2020-06-24 9:53 ` David Hildenbrand
2020-06-24 11:16 ` 孙世龙 sunshilong
2020-06-24 17:22 ` David Rientjes
2020-06-25 3:22 ` 孙世龙 sunshilong
2020-06-28 3:27 ` David Rientjes [this message]
2020-06-28 5:15 ` 孙世龙 sunshilong
2020-06-28 20:39 ` David Rientjes
-- strict thread matches above, loose matches on Subject: below --
2020-06-23 15:39 孙世龙 sunshilong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.22.394.2006272023080.589812@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=sunshilong369@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).