linux-kernel - Re: [RFC] mm/migrate: Add new migration reason MR

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:   Tue, 30 Jan 2018 18:40:58 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>,
        Michal Hocko <mhocko@...nel.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        akpm@...ux-foundation.org
Subject: Re: [RFC] mm/migrate: Add new migration reason MR_HUGETLB

On 01/30/2018 06:25 PM, Anshuman Khandual wrote:
> On 01/30/2018 01:29 PM, Michal Hocko wrote:
>> On Tue 30-01-18 08:37:14, Anshuman Khandual wrote:
>>> alloc_contig_range() initiates compaction and eventual migration for
>>> the purpose of either CMA or HugeTLB allocation. At present, reason
>>> code remains the same MR_CMA for either of those cases. Lets add a
>>> new reason code which will differentiate the purpose of migration
>>> as HugeTLB allocation instead.
>> Why do we need it?
> 
> The same reason why we have MR_CMA (maybe some other ones as well) at
> present, for reporting purpose through traces at the least. It just
> seemed like same reason code is being used for two different purpose
> of migration.
> 

I was 'thinking' that we could potentially open up alloc_contig_range()
for more general purpose use.  Users would not call alloc_contig_range
directly, but it would be wrapped in a more user friendly API.  Or,
perhaps it gets modified and becomes something else.  Still just thinking
as part of "how do we provide a more general purpose interface for
allocation of more than MAX_ORDER contiguous pages?".

Not sure that we should be adding to the current alloc_contig_range
interface until we decide it is something which will be useful long term.
-- 
Mike Kravetz