lkml.org 
[lkml]   [2009]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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



\
 
 \ /
  Last update: 2009-10-13 02:13    [W:0.164 / U:4.976 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site