All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Muchun Song <songmuchun@bytedance.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages
Date: Wed, 17 Feb 2021 15:23:37 +0100	[thread overview]
Message-ID: <20210217142321.GA651@linux> (raw)
In-Reply-To: <5d70b340-2db0-ef1f-1564-e5d39354c11c@redhat.com>

On Wed, Feb 17, 2021 at 03:08:04PM +0100, David Hildenbrand wrote:
> On 17.02.21 14:59, Michal Hocko wrote:
> > On Wed 17-02-21 14:53:37, David Hildenbrand wrote:
> > > On 17.02.21 14:50, Michal Hocko wrote:
> > [...]
> > > > Do we have any real life examples? Or does this fall more into, let's
> > > > optimize an existing implementation category.
> > > > 
> > > 
> > > It's a big TODO item I have on my list and I am happy that Oscar is looking
> > > into it. So yes, I noticed it while working on virtio-mem. It's real.
> > 
> > Do not take me wrong, I am not opposing to the functionality. I am
> > asking for the specific usecase.
> 
> Makes sense, and a proper motivation should be included in the patches/cover
> letter. So here comes a quick-n-dirty example:

Definitely. I took it for granted that the problem was obvious.

> Start a VM with 4G. Hotplug 1G via virtio-mem and online it to ZONE_MOVABLE.
> Allocate 512 huge pages.
> 
> [root@localhost ~]# cat /proc/meminfo
> MemTotal:        5061512 kB
> MemFree:         3319396 kB
> MemAvailable:    3457144 kB
> ...
> HugePages_Total:     512
> HugePages_Free:      512
> HugePages_Rsvd:        0
> HugePages_Surp:        0
> Hugepagesize:       2048 kB
> 
> 
> The huge pages get partially allocate from ZONE_MOVABLE. Try unplugging 1G
> via virtio-mem (remember, all ZONE_MOVABLE). Inside the guest:
> 
> [  180.058992] alloc_contig_range: [1b8000, 1c0000) PFNs busy
> [  180.060531] alloc_contig_range: [1b8000, 1c0000) PFNs busy
> [  180.061972] alloc_contig_range: [1b8000, 1c0000) PFNs busy
> [  180.063413] alloc_contig_range: [1b8000, 1c0000) PFNs busy
> [  180.064838] alloc_contig_range: [1b8000, 1c0000) PFNs busy
> [  180.065848] alloc_contig_range: [1bfc00, 1c0000) PFNs busy
> [  180.066794] alloc_contig_range: [1bfc00, 1c0000) PFNs busy
> [  180.067738] alloc_contig_range: [1bfc00, 1c0000) PFNs busy
> [  180.068669] alloc_contig_range: [1bfc00, 1c0000) PFNs busy
> [  180.069598] alloc_contig_range: [1bfc00, 1c0000) PFNs busy
> 
> 
> I succeed in unplugging 540MB - 484 MB remain blocked by huge pages ("which
> did not end up there by pure luck"). These pages are movable (and even
> free!) and can easily be reallocated.

Thanks for providing such a detailed case David.
I will gather the bits and prepare a v2 once I gather more feedback.

-- 
Oscar Salvador
SUSE L3


  parent reply	other threads:[~2021-02-17 14:23 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-17 10:08 [PATCH 0/2] Make alloc_contig_range handle Hugetlb pages Oscar Salvador
2021-02-17 10:08 ` [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages Oscar Salvador
2021-02-17 13:30   ` Michal Hocko
2021-02-17 13:36     ` David Hildenbrand
2021-02-17 13:50       ` Michal Hocko
2021-02-17 13:53         ` David Hildenbrand
2021-02-17 13:59           ` Michal Hocko
2021-02-17 14:08             ` David Hildenbrand
2021-02-17 14:14               ` Michal Hocko
2021-02-17 14:23               ` Oscar Salvador [this message]
2021-02-17 13:42     ` Oscar Salvador
2021-02-17 15:00   ` Michal Hocko
2021-02-18 10:09     ` Oscar Salvador
2021-02-18 12:52       ` Michal Hocko
2021-02-18 13:32         ` Oscar Salvador
2021-02-18 13:59           ` Michal Hocko
2021-02-18 16:53             ` Oscar Salvador
2021-02-19  9:05             ` Oscar Salvador
2021-02-19  9:56               ` Michal Hocko
2021-02-19 10:14                 ` Oscar Salvador
2021-02-19 20:00                   ` Mike Kravetz
2021-02-19 10:40                 ` Oscar Salvador
2021-02-19 10:55                   ` Michal Hocko
2021-02-19 11:17                     ` Oscar Salvador
2021-02-19 11:24                       ` Michal Hocko
2021-02-17 10:08 ` [PATCH 2/2] mm: Make alloc_contig_range handle in-use " Oscar Salvador
2021-02-17 13:36   ` Michal Hocko
2021-02-17 13:46     ` Oscar Salvador
2021-02-17 13:54       ` Michal Hocko
2021-02-17 15:06   ` Michal Hocko
2021-02-17 15:27     ` Oscar Salvador
2021-02-17 15:33       ` Michal Hocko
2021-02-18  6:01         ` Oscar Salvador

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=20210217142321.GA651@linux \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.com \
    --cc=songmuchun@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.