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]
Message-ID: <alpine.DEB.2.10.1503061312170.10330@chino.kir.corp.google.com>
Date:	Fri, 6 Mar 2015 13:14:43 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Mike Kravetz <mike.kravetz@...cle.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 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).
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ