linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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: Sun, 28 Jun 2020 13:39:24 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2006281336160.708072@chino.kir.corp.google.com> (raw)
In-Reply-To: <CAAvDm6baQXikeZPXsF1sFG6mP2k5cgKspwp51j+qcw_P9EEjZQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Sun, 28 Jun 2020, 孙世龙 sunshilong wrote:

>      >>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?
> 

Without compaction and migration, we don't have the ability to move pages 
around for defragmentation so any strategy can only be used at allocation 
time.

__rmqueue_smallest() will attempt to take the smallest possible free page 
to leave higher order pages available in an attempt to consolidate 
allocations on the smallest set of pageblocks as possible given the 
allocation migratetype.

When we do have to fallback to a pageblock of a different migratetype, we 
take the largest possible free page and convert it over if it's at least 
half free for subsequent allocations of the desired migratetype.

That's the extent that we can do this at allocation time.

  reply	other threads:[~2020-06-28 20:39 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
2020-06-28  5:15           ` 孙世龙 sunshilong
2020-06-28 20:39             ` David Rientjes [this message]
  -- 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.2006281336160.708072@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).