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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

From: Michael Kerrisk <mtk.manpages@...>

To: Peter Zijlstra <a.p.zijlstra@...>

Cc: Michael Kerrisk <mtk.manpages@...>, Eugene Teo <eugeneteo@...>, <linux-kernel@...>, Neil Horman <nhorman@...>, Ingo Molnar <mingo@...>

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

Date: Friday, April 11, 2008 - 5:16 am

On Fri, Apr 11, 2008 at 11:01 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
quoted text> 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@chello.nl> 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?



-- 
Michael Kerrisk
Maintainer of the Linux man-pages project
http://www.kernel.org/doc/man-pages/
Want to report a man-pages bug? Look here:
http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
unsubscribe noticeTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:

[PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Eugene Teo, (Fri Feb 8, 10:59 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Fri Feb 8, 11:10 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Thu Feb 28, 11:12 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Thu Feb 28, 11:21 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 4:56 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Fri Apr 11, 5:01 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 5:16 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Fri Apr 11, 5:21 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 5:27 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Fri Apr 11, 5:32 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 5:38 am)

RLIMIT_RTTIME documentation for getrlimit.2, Michael Kerrisk, (Fri Apr 18, 12:52 pm)

Re: RLIMIT_RTTIME documentation for getrlimit.2, Michael Kerrisk, (Mon Apr 28, 7:44 am)

Re: RLIMIT_RTTIME documentation for getrlimit.2, Peter Zijlstra, (Mon Apr 28, 8:09 am)

Re: RLIMIT_RTTIME documentation for getrlimit.2, Michael Kerrisk, (Mon Apr 28, 8:14 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Neil Horman, (Fri Feb 29, 8:32 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Thu Feb 28, 11:44 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Thu Feb 28, 11:50 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 3:38 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Peter Zijlstra, (Fri Apr 11, 3:45 am)

Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits, Michael Kerrisk, (Fri Apr 11, 4:01 am)


linux-kernel:
Greg KH	Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3
Greg KH	[GIT PATCH] driver core patches against 2.6.24
Andrew Morton	Re: 2.6.23-rc6-mm1
Luciano Rocha	usb hdd problems with 2.6.27.2
git:

linux-netdev:
Gerrit Renker	[PATCH 15/37] dccp: Set per-connection CCIDs via socket options
Andrew Morton	Re: [BUG] New Kernel Bugs
David Miller	[GIT]: Networking
Jarek Poplawski	[PATCH take 2] pkt_sched: Protect gen estimators under est_lock.
openbsd-misc:

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

Online users