Re: Bug#533708: ITP: libhugetlbfs -- Tools and Library access huge pages of memory
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 [cjwatson@debian.org]
Reply to: