On Wed, Feb 17, 2021 at 03:08:04PM +0100, 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:

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