On Tue, Mar 23, 2010 at 02:14:51AM +0100, Frank Lin PIAT wrote: > On Tue, 2010-03-23 at 01:20 +0100, Frank Lin PIAT wrote: > > This ITP was stalled, so I packaged this tool... > > > > * Package name : libhugetlbfs > > Description : Tools and Library access huge pages of memory > > > > ::hugepages:: > > Description: A set of tools to configure huge pages of memory > > This package contains a number of utilities that will help administrate > > the use of huge pages on your system. hugeedit modifies binaries to > > set default segment remapping behavior. hugectl sets environment > > variables for using huge pages and then execs the target program. > > hugeadm gives easy access to huge page pool size control. pagesize > > lists page sizes available on the machine. > > I would like some advice regarding HugePage/HugeTlbFs. I wonder If I > should request a fixed GID... > > To grant a user the right to use hugepages, that user have to be in a > group that can be used in one or more of : > > 1. hugetlbfs mountpoints permission > 2. Sysctl's vm.hugetlb_shm_group = GIDNUMBER > 3. /etc/security/limits.conf's memlock > > For #1 and #3, it is possible to use the group name. But unfortunately, > sysctl only accept GID number. > > Is it sufficient reason to request a fixed GID? Alternatively, we could > use an init script to do the conversion. I don't like that option very > much, because I think it would be better to let /etc/sysctl handle it.
As base-passwd maintainer, this is in principle sufficient reason for a fixed GID. However, I'm concerned about the management procedures and wouldn't want to allocate a GID before it's clear that this has been thought through properly. Who should be able to use huge pages? What basis should a system administrator use to determine who should be added to this group? We need to work this out *before* adding the group. I have to say that a group feels like a very odd way to manage this to me - surely this is more like what we traditionally manage using resource limits, which might be associated with groups but might also be associated with other properties of PAM sessions or with particular applications? I know there's some mention of resource limits in the wiki page you cited, but it seems to be secondary to the ability to create files in this virtual filesystem. Normally, I would not allocate any new entries in the global static range (0-99) without an extraordinarily good overriding reason. An entry in the static on-demand range (60000-64999) would be more usual, but requires a package to own it and actually create the group using addgroup. Doing this in a run-time library package is problematic because what if its SONAME changes? If at all possible, I would prefer it if any package owning such a group has a stable name and is one you're prepared to say will stick around for a long time. I think that the mount point should be handled dynamically, in a new init script or perhaps even in mountkernfs (or mountdevsubfs if you decide to put the mount point under /dev), rather than by requiring everyone who wants to use this to edit /etc/fstab. (This seems to be partially covered by #572733.) (You could of course work around my objections by using a dynamic GID and an init script, but I agree with you that that is not so desirable.) -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323085637.gg4...@riva.ucam.org
