Messages in this thread |  | | | Date | Mon, 12 Oct 2009 20:06:01 -0400 | | From | Neil Horman <> | | Subject | Re: [PATCH 0/3] extend get/setrlimit to support setting rlimits external to a process (v5) |
| |
On Mon, Oct 12, 2009 at 02:58:10PM -0700, Andrew Morton wrote: > On Mon, 12 Oct 2009 12:13:42 -0400 > Neil Horman <nhorman@tuxdriver.com> wrote: > > > Its been requested often that we have the ability to read and modify process > > rlimit values from contexts external to the owning process. Ideally this allows > > sysadmins to adjust rlimits on long running processes wihout the need to stop > > and restart those processes, which incurs undesireable downtime. This patch > > enables that functionality, It does so in two places. First it enables process > > limit setting by writing to the /proc/pid/limits file a string in the format: > > <limit> <current limit> <max limit> > /proc/<pid>/limits > > where limit is one of > > [as,core,cpu,data,fsize,locks,memlock,msgqueue,nice,nofile,nproc,rss,rtprio,rttime] > > > > Secondly it allows for programatic setting of these limits via 2 new syscalls, > > getprlimit, and setprlimit, which act in an identical fashion to getrlimit and > > setrlimit respectively, except that they except a process id as an extra > > argument, to specify the process id of the rlimit values that you wish to > > read/write > > I'm still not seeing why we need the /proc interface. > > We've been using a syscall to set rlimits for ever and we've survived. > Except that we haven't. We've had the read side of the proc interface for years now, simply because people asked for it. We could have add getprlimit back then, but we didn't because users liked this. Its easy, its obvious, and and it doesn't require a sysadmin to remember the name of another utility.
> It just adds bloat and complexity to the kernel because putting a > 100-line tool into util-linux is All Too Hard. > And, with the adjustments to support the getprlimit/setprlimit syscalls in this series, the net additional code to support a writeable /proc interface totals about 80 lines. I really think 'bloat' is a bit of an overstatement here. If you're really that worried about it, we can surround the proc interface with a config option. But at this point people have become acoustomed to having /proc/pid/limits available, I don't see why 80 lines to add the ability to set limits is really that much of a barrier.
Neil
|  |