Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits

[Peter Zijlstra]

On Fri, 2008-04-11 at 11:16 +0200, Michael Kerrisk wrote:
> On Fri, Apr 11, 2008 at 11:01 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> > On Fri, 2008-04-11 at 10:56 +0200, Michael Kerrisk wrote:
> > > On Thu, Feb 28, 2008 at 5:21 PM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> wrote:
> > > >
> > > > On Thu, 2008-02-28 at 16:12 +0100, Michael Kerrisk wrote:
> > > > > Peter,
> > > > >
> > > > > Could you please provide some text describing RLIMIT_RTTIMEfor the
> > > > > getrlimit.2 man page.
> > > >
> > > > The rlimit sets a timeout in [us] for SCHED_RR and SCHED_FIFO tasks.
> > > > This time is measured between sleeps, so a schedule in RR or a
> > > > preemption in either is not a sleep - the task needs to be dequeued and
> > > > enqueued for the timer to reset.
> > > >
> > > > Upon reaching the cur limit we start giving SIGXCPU every second, upon
> > > > reaching the hard limit we give SIGKILL - matching RLIMIT_CPU.
> > > >
> > > > Time is measured in tick granularity (for now).
> > >
> > > So I have another question: why is the granularity of this rlimit
> > > microseconds?  On the one hand, specifying limits down at the
> > > microsecond level seems (to my naive eye) unlikely to be useful.  (But
> > > perhaps I have missed a thread where this was explained.)  On the
> > > other hand, it means that on 32-bit the largest time limit we can set
> > > is ~4000 seconds, and I wonder if there are scenarios where it might
> > > be useful to have larger limits than that.
> > >
> > > Why not, for example, have a granularity of milliseconds?
> >
> > The us scale seemed the best fit in that it allows sub-ms granularity
> > while still allowing for quite long periods too. I'd preferred ns scale
> > as that is what we use throughout the scheduler where possible - but
> > that seemed too restrictive at the high end.
> >
> > No real hard arguments either way.
> 
> I'm curious: what scenarios require sub-millisecond timeouts?

I'm not sure, nor will they actually work atm since its tick based. But
I'm not wanting to exclude too many things, and 4k second upper limit is
plenty large.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/