Message-ID: <20171002140632.GA12673@gmail.com>
Date:   Mon, 2 Oct 2017 16:06:33 +0200
From:   Alexandru Moise <00moses.alexander00@...il.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     corbet@....net, paulmck@...ux.vnet.ibm.com,
        akpm@...ux-foundation.org, tglx@...utronix.de, mingo@...nel.org,
        cdall@...aro.org, mchehab@...nel.org, zohar@...ux.vnet.ibm.com,
        marc.zyngier@....com, rientjes@...gle.com, hannes@...xchg.org,
        mike.kravetz@...cle.com, n-horiguchi@...jp.nec.com,
        aneesh.kumar@...ux.vnet.ibm.com, punit.agrawal@....com,
        aarcange@...hat.com, gerald.schaefer@...ibm.com,
        jglisse@...hat.com, kirill.shutemov@...ux.intel.com,
        will.deacon@....com, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH] mm,hugetlb,migration: don't migrate kernelcore hugepages

On Mon, Oct 02, 2017 at 02:54:32PM +0200, Michal Hocko wrote:
> On Mon 02-10-17 00:51:11, Alexandru Moise wrote:
> > This attempts to bring more flexibility to how hugepages are allocated
> > by making it possible to decide whether we want the hugepages to be
> > allocated from ZONE_MOVABLE or to the zone allocated by the "kernelcore="
> > boot parameter for non-movable allocations.
> > 
> > A new boot parameter is introduced, "hugepages_movable=", this sets the
> > default value for the "hugepages_treat_as_movable" sysctl. This allows
> > us to determine the zone for hugepages allocated at boot time. It only
> > affects 2M hugepages allocated at boot time for now because 1G
> > hugepages are allocated much earlier in the boot process and ignore
> > this sysctl completely.
> > 
> > The "hugepages_treat_as_movable" sysctl is also turned into a mandatory
> > setting that all hugepage allocations at runtime must respect (both
> > 2M and 1G sized hugepages). The default value is changed to "1" to
> > preserve the existing behavior that if hugepage migration is supported,
> > then the pages will be allocated from ZONE_MOVABLE.
> > 
> > Note however if not enough contiguous memory is present in ZONE_MOVABLE
> > then the allocation will fallback to the non-movable zone and those
> > pages will not be migratable.
> 
> This changelog doesn't explain _why_ we would need something like that.
> 

So people shouldn't be able to choose whether their hugepages should be
migratable or not? Maybe they consider some of their applications more
important than others.

Say:
You have a large number of correctable errors on a subpage of a compound
page. So you copy the contents of the page to another hugepage, break the
original page and offline the subpage. But maybe you'd rather that some of
your hugepages not be broken and moved because you're not that worried about
memory corruption, but more about availability.

Without this patch even if hugepages are in the non-movable zone, they move.

> > The implementation is a bit dirty so obviously I'm open to suggestions
> > for a better way to implement this behavior, or comments whether the whole
> > idea is fundamentally __wrong__.
> 
> To be honest I think this is just a wrong approach. hugepages_treat_as_movable
> is quite questionable to be honest because it breaks the basic semantic
> of the movable zone if the hugetlb pages are not really migratable which
> should be the only criterion. Hugetlb pages are no different from other
> migratable pages in that regards.

Shouldn't hugepages allocated to unmovable zone, by definition, not be able
to be migrated? With this patch, hugepages in the movable zone do move, but
hugepages in the non-movable zone don't. Or am I misunderstanding the semantics
completely?

../Alex
> -- 
> Michal Hocko
> SUSE Labs

Powered by blists - more mailing lists