Re: [RFC PATCH] mm,memory_hotplug: Unlock 1GB-hugetlb on x86_64
From: Oscar Salvador
Date: Thu Feb 28 2019 - 16:01:42 EST
On Thu, Feb 28, 2019 at 03:08:17PM +0100, Michal Hocko wrote:
> On Thu 28-02-19 14:40:54, Oscar Salvador wrote:
> > On Thu, Feb 28, 2019 at 01:11:15PM +0100, Michal Hocko wrote:
> > > On Thu 28-02-19 11:19:52, Oscar Salvador wrote:
> > > > On Thu, Feb 28, 2019 at 10:55:35AM +0100, Michal Hocko wrote:
> > > > > You seemed to miss my point or I am wrong here. If scan_movable_pages
> > > > > skips over a hugetlb page then there is nothing to migrate it and it
> > > > > will stay in the pfn range and the range will not become idle.
> > > >
> > > > I might be misunterstanding you, but I am not sure I get you.
> > > >
> > > > scan_movable_pages() can either skip or not a hugetlb page.
> > > > In case it does, pfn will be incremented to skip the whole hugetlb
> > > > range.
> > > > If that happens, pfn will hold the next non-hugetlb page.
> > >
> > > And as a result the previous hugetlb page doesn't get migrated right?
> > > What does that mean? Well, the page is still in use and we cannot
> > > proceed with offlining because the full range is not isolated right?
> >
> > I might be clumsy today but I still fail to see the point of concern here.
>
> No, it's me who is daft. I have misread the patch and seen that also
> page_huge_active got removed. Now it makes perfect sense to me because
> active pages are still handled properly.
Heh, no worries.
Glad we got the point, I was just scratching my head like a monkey.
> I will leave the decision whether to split up the patch to you.
On a second thought, I will split it up.
One of the changes is merely to remove a redundant check, while the other is
actually the one that enables the system to be able to proceed with gigantic
pages, so not really related.
> Acked-by: Michal Hocko <mhocko@xxxxxxxx>
Thanks!
--
Oscar Salvador
SUSE L3