linux-kernel - Re: [RFC 0/3] hugetlbfs: optionally reserve all fs pages at mount time

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] [day] [month] [year] [list]

Message-ID: <54FA1CFE.1000500@oracle.com>
Date:	Fri, 06 Mar 2015 13:32:46 -0800
From:	Mike Kravetz <mike.kravetz@...cle.com>
To:	David Rientjes <rientjes@...gle.com>
CC:	Michal Hocko <mhocko@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	Aneesh Kumar <aneesh.kumar@...ux.vnet.ibm.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [RFC 0/3] hugetlbfs: optionally reserve all fs pages at mount
 time

On 03/06/2015 01:14 PM, David Rientjes wrote:
> On Fri, 6 Mar 2015, Mike Kravetz wrote:
>
>> Thanks for the CONFIG_CGROUP_HUGETLB suggestion, however I do not
>> believe this will be a satisfactory solution for my usecase.  As you
>> point out, cgroups could be set up (by a sysadmin) for every hugetlb
>> user/application.  In this case, the sysadmin needs to have knowledge
>> of every huge page user/application and configure appropriately.
>>
>> I was approaching this from the point of view of the application.  The
>> application wants the guarantee of a minimum number of huge pages,
>> independent of other users/applications.  The "reserve" approach allows
>> the application to set aside those pages at initialization time.  If it
>> can not get the pages it needs, it can refuse to start, or configure
>> itself to use less, or take other action.
>>
>
> Would it be too difficult to modify the application to mmap() the
> hugepages at startup so they are no longer free in the global pool but
> rather get marked as reserved so other applications cannot map them?  That
> should return MAP_FAILED if there is an insufficient number of hugepages
> available to be reserved (HugePages_Rsvd in /proc/meminfo).

The application is a database with multiple processes/tasks that will
come and go over time.  I thought about having one task do a big
mmap() at initialization time, but then the issue is how to coordinate
with the other tasks and their requests to allocate/free pages.

-- 
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/