Re: [PATCH 1/2] mm: Make alloc_contig_range handle free hugetlb pages
From: Michal Hocko <mhocko@suse.com>
Date: 2021-02-17 14:16:03
Also in:
lkml
On Wed 17-02-21 15:08:04, David Hildenbrand wrote:
On 17.02.21 14:59, Michal Hocko wrote:quoted
On Wed 17-02-21 14:53:37, David Hildenbrand wrote:quoted
On 17.02.21 14:50, Michal Hocko wrote:[...]quoted
quoted
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: 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.
OK, this sounds reasonable. -- Michal Hocko SUSE Labs