On Wed 17-02-21 15:08:04, 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:
>
>
> 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
