linux-kernel - Re: [PATCH] mm,hugetlb,migration: don't migrate kernelcore hugepages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 2 Oct 2017 16:27:17 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Alexandru Moise <00moses.alexander00@...il.com>
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 02-10-17 16:06:33, Alexandru Moise wrote:
> 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?

How are hugetlb pages any different from THP wrt. migrateability POV? Or
any other mapped memory to the userspace in general?

> Maybe they consider some of their applications more important than
> others.

I do not understand this part.

> 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. 

I suspect you have HWPoisoning in mind right?

> 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.

Could you be more specific please?

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

which is ok. This is very same with any other movable allocations.
 
> > > 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?

yes. movable zone is only about a guarantee to move memory around.
Movable allocations are still allowed to use kernel zones (aka
non-movable). The main reason for the movable zone these days is memory
hotplug which needs a semi-guarantee that the memory used can be
migrated elsewhere to free up the offlined memory.

-- 
Michal Hocko
SUSE Labs