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

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

[Eugene Teo]

RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
/proc/<pid>/limits with the new rlimit.

Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index c59852b..dcf7be8 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
 	[RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
 	[RLIMIT_NICE] = {"Max nice priority", NULL},
 	[RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
+	[RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
 };
 
 /* Display limits for a process */
-- 

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

[Peter Zijlstra]

On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
> RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
> real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
> /proc/<pid>/limits with the new rlimit.

Ah, didn't know about that file, thanks!

> Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

> ---
>  fs/proc/base.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c59852b..dcf7be8 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
>  	[RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
>  	[RLIMIT_NICE] = {"Max nice priority", NULL},
>  	[RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
> +	[RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
>  };
>  
>  /* Display limits for a process */

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

[Michael Kerrisk]

Peter,

Could you please provide some text describing RLIMIT_RTTIMEfor the
getrlimit.2 man page.

Cheers,

Michael

On Fri, Feb 8, 2008 at 4:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
> > RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
> > real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
> > /proc/<pid>/limits with the new rlimit.
>
> Ah, didn't know about that file, thanks!
>
> > Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
>
> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
>
> > ---
> >  fs/proc/base.c |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > index c59852b..dcf7be8 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
> >       [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
> >       [RLIMIT_NICE] = {"Max nice priority", NULL},
> >       [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
> > +     [RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
> >  };
> >
> >  /* Display limits for a process */
>
> --
> To 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/
>



-- 
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com

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

[Peter Zijlstra]

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).

> Cheers,
> 
> Michael
> 
> On Fri, Feb 8, 2008 at 4:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
> > > RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
> > > real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
> > > /proc/<pid>/limits with the new rlimit.
> >
> > Ah, didn't know about that file, thanks!
> >
> > > Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
> >
> > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >
> >
> > > ---
> > >  fs/proc/base.c |    1 +
> > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > > index c59852b..dcf7be8 100644
> > > --- a/fs/proc/base.c
> > > +++ b/fs/proc/base.c
> > > @@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
> > >       [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
> > >       [RLIMIT_NICE] = {"Max nice priority", NULL},
> > >       [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
> > > +     [RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
> > >  };
> > >
> > >  /* Display limits for a process */
> >
> > --
> > To 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/
> >
> 
> 
> 

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

[Michael Kerrisk]

Peter,

Thanks for the text.

On Thu, Feb 28, 2008 at 4: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.

Just to clarify: sleep here means a call to some blocking syscall
(e.g., nanosleep(), read(), select(), etc.), right?  Is there anything
else that falls under the category of "sleep"?  What about a call to
sched_yield() where the process explicitly lets go of the CPU?

Also, is this limit per-thread or per-process?  I assume the latter --
but can you confirm please.

Cheers,

Michael

>  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).
>
>
>
>  > Cheers,
>  >
>  > Michael
>  >
>  > On Fri, Feb 8, 2008 at 4:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>  > >
>  > > On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
>  > > > RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
>  > > > real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
>  > > > /proc/<pid>/limits with the new rlimit.
>  > >
>  > > Ah, didn't know about that file, thanks!
>  > >
>  > > > Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
>  > >
>  > > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>  > >
>  > >
>  > > > ---
>  > > >  fs/proc/base.c |    1 +
>  > > >  1 files changed, 1 insertions(+), 0 deletions(-)
>  > > >
>  > > > diff --git a/fs/proc/base.c b/fs/proc/base.c
>  > > > index c59852b..dcf7be8 100644
>  > > > --- a/fs/proc/base.c
>  > > > +++ b/fs/proc/base.c
>  > > > @@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
>  > > >       [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
>  > > >       [RLIMIT_NICE] = {"Max nice priority", NULL},
>  > > >       [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
>  > > > +     [RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
>  > > >  };
>  > > >
>  > > >  /* Display limits for a process */
>  > >
>  > > --
>  > > To 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/
>  > >
>  >
>  >
>  >
>
>



-- 
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

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

[Peter Zijlstra]

On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote:
> Peter,
> 
> Thanks for the text.
> 
> On Thu, Feb 28, 2008 at 4: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.
> 
> Just to clarify: sleep here means a call to some blocking syscall
> (e.g., nanosleep(), read(), select(), etc.), right?  Is there anything
> else that falls under the category of "sleep"?  What about a call to
> sched_yield() where the process explicitly lets go of the CPU?

Yes, and yes, others would be blocking on futexes and the like.

> Also, is this limit per-thread or per-process?  I assume the latter --
> but can you confirm please.

Per process. Requests have been made to allow for per thread, but
rlimits are not.

Its really not meant as a fine-grained deadline notification mechanism,
we have posix timers for that, but as a watchdog to ensure we behave
'well'.

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

[Neil Horman]

On Thu, Feb 28, 2008 at 04:21:40PM +0100, Peter Zijlstra 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).
> 
> > Cheers,
> > 
> > Michael
> > 
> > On Fri, Feb 8, 2008 at 4:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > >
> > > On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
> > > > RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
> > > > real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
> > > > /proc/<pid>/limits with the new rlimit.
> > >
> > > Ah, didn't know about that file, thanks!
> > >
> > > > Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
> > >
> > > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: Neil Horman <nhorman@tuxdriver.com>


-- 
/****************************************************
 * Neil Horman <nhorman@tuxdriver.com>
 * Software Engineer, Red Hat
 ****************************************************/

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

[Michael Kerrisk]

On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote:
> > Peter,
> >
> > Thanks for the text.
> >
> > On Thu, Feb 28, 2008 at 4: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.
> >
> > Just to clarify: sleep here means a call to some blocking syscall
> > (e.g., nanosleep(), read(), select(), etc.), right?  Is there anything
> > else that falls under the category of "sleep"?  What about a call to
> > sched_yield() where the process explicitly lets go of the CPU?
>
> Yes, and yes, others would be blocking on futexes and the like.

Peter,

I've been testing this patch.  Above you seemed to be saying that
doing a sched_yield() would be equivalent to a sleep, causing the rt
counter to be reset to zero.  Howver, the results I'm seeing suggest
that a sched_yield() does not cause the counter to be reset to zero
(i.e., despite calling sched_yield() at frequent intervals, the
process still encounters the RLIM_RTTIME soft limit and gets SIGXCPU).
 Can you comment?

Cheers,

Michael
-- 
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

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

[Peter Zijlstra]

On Fri, 2008-04-11 at 09:38 +0200, Michael Kerrisk wrote:
> On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote:
> > > Peter,
> > >
> > > Thanks for the text.
> > >
> > > On Thu, Feb 28, 2008 at 4: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.
> > >
> > > Just to clarify: sleep here means a call to some blocking syscall
> > > (e.g., nanosleep(), read(), select(), etc.), right?  Is there anything
> > > else that falls under the category of "sleep"?  What about a call to
> > > sched_yield() where the process explicitly lets go of the CPU?
> >
> > Yes, and yes, others would be blocking on futexes and the like.
> 
> Peter,
> 
> I've been testing this patch.  Above you seemed to be saying that
> doing a sched_yield() would be equivalent to a sleep, causing the rt
> counter to be reset to zero.  Howver, the results I'm seeing suggest
> that a sched_yield() does not cause the counter to be reset to zero
> (i.e., despite calling sched_yield() at frequent intervals, the
> process still encounters the RLIM_RTTIME soft limit and gets SIGXCPU).
>  Can you comment?

It appears you are right. I must have been staring at something else
than code when I said that :-(, yield() will indeed _not_ reset the
counter.

Now, I think it makes some sense to reset it, because we do try to play
nice by calling yield. OTOH we don't actually block and become
unrunnable - we'll still be contending for CPU time.

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

[Michael Kerrisk]

On 4/11/08, Michael Kerrisk <mtk.manpages@googlemail.com> wrote:
> On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>  >
>  > On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote:

[...]

>  > I've been testing this patch.  Above you seemed to be saying that
>  > doing a sched_yield() would be equivalent to a sleep, causing the rt
>  > counter to be reset to zero.  Howver, the results I'm seeing suggest
>  > that a sched_yield() does not cause the counter to be reset to zero
>  > (i.e., despite calling sched_yield() at frequent intervals, the
>  > process still encounters the RLIM_RTTIME soft limit and gets SIGXCPU).
>  >  Can you comment?
>
>
> It appears you are right. I must have been staring at something else
>  than code when I said that :-(, yield() will indeed _not_ reset the
>  counter.
>
>  Now, I think it makes some sense to reset it, because we do try to play
>  nice by calling yield. OTOH we don't actually block and become
>  unrunnable - we'll still be contending for CPU time.

On the one hand, it seems reasonable to reset the counter.  The POSIX
definition of sched_yield() says that it "shall force the running
thread to relinquish the processor until it again becomes the head of
its thread list".

On the other hand, what if this is the only runnable real-time
process?  Then sched_yield() is effectively a no-op, and a runaway
process could lock up the system (which I gather is what RLIMIT_RTTIME
was primarily designed to prevent).

I don't really have a strong leaning either way about what should be
done, other than that we should probably make a specific choice, and
document it in the setrlimit(2) man page.

Cheers,

Michael
-- 
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com

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

[Michael Kerrisk]

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?

Cheers,

Michael


> > On Fri, Feb 8, 2008 at 4:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > >
> > > On Fri, 2008-02-08 at 22:59 +0800, Eugene Teo wrote:
> > > > RLIMIT_RTTIME was introduced to allow the user to set a runtime timeout on
> > > > real-time tasks: http://lkml.org/lkml/2007/12/18/218. This patch updates
> > > > /proc/<pid>/limits with the new rlimit.
> > >
> > > Ah, didn't know about that file, thanks!
> > >
> > > > Signed-off-by: Eugene Teo <eugeneteo@kernel.sg>
> > >
> > > Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > >
> > >
> > > > ---
> > > >  fs/proc/base.c |    1 +
> > > >  1 files changed, 1 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/fs/proc/base.c b/fs/proc/base.c
> > > > index c59852b..dcf7be8 100644
> > > > --- a/fs/proc/base.c
> > > > +++ b/fs/proc/base.c
> > > > @@ -412,6 +412,7 @@ static const struct limit_names lnames[RLIM_NLIMITS] = {
> > > >       [RLIMIT_MSGQUEUE] = {"Max msgqueue size", "bytes"},
> > > >       [RLIMIT_NICE] = {"Max nice priority", NULL},
> > > >       [RLIMIT_RTPRIO] = {"Max realtime priority", NULL},
> > > > +     [RLIMIT_RTTIME] = {"Max realtime timeout", "us"},
> > > >  };
> > > >
> > > >  /* Display limits for a process */
> > >
> > > --
> > > To 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/
> > >
> >
> >
> >
>
>



-- 
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

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

[Peter Zijlstra]

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.

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

[Michael Kerrisk]

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

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@chello.nl> 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@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?

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.

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

[Michael Kerrisk]

On Fri, Apr 11, 2008 at 11:21 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> 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@chello.nl> 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@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?
>
> I'm not sure, nor will they actually work atm since its tick based.

Just to make sure me and the man page are clear: by tick-based, you
mean the granularity is in jiffies, right?

> But
> I'm not wanting to exclude too many things, and 4k second upper limit is
> plenty large.

Okay.

And following on from my other conversation in this thread...  What
should/will be the specified behavior w.r.t. resetting or not
resetting the timer on a sched_yield()?

Cheers,

Michael

-- 
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

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

[Peter Zijlstra]

On Fri, 2008-04-11 at 11:27 +0200, Michael Kerrisk wrote:
> On Fri, Apr 11, 2008 at 11:21 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> >
> > 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@chello.nl> 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@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?
> >
> > I'm not sure, nor will they actually work atm since its tick based.
> 
> Just to make sure me and the man page are clear: by tick-based, you
> mean the granularity is in jiffies, right?

Yes, they are currently jiffy based - but I could do hrtimer if someone
shows need.

> > But
> > I'm not wanting to exclude too many things, and 4k second upper limit is
> > plenty large.
> 
> Okay.
> 
> And following on from my other conversation in this thread...  What
> should/will be the specified behavior w.r.t. resetting or not
> resetting the timer on a sched_yield()?

I think I'll keep it as is; so sched_yield() will _not_ reset the
counter. The rationale is that the process didn't actually stop running
- it just got scheduled away.

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

[Michael Kerrisk]

On Fri, Apr 11, 2008 at 11:32 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> On Fri, 2008-04-11 at 11:27 +0200, Michael Kerrisk wrote:
> > On Fri, Apr 11, 2008 at 11:21 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > >
> > > 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@chello.nl> 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@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?
> > >
> > > I'm not sure, nor will they actually work atm since its tick based.
> >
> > Just to make sure me and the man page are clear: by tick-based, you
> > mean the granularity is in jiffies, right?
>
> Yes, they are currently jiffy based - but I could do hrtimer if someone
> shows need.
>
> > > But
> > > I'm not wanting to exclude too many things, and 4k second upper limit is
> > > plenty large.
> >
> > Okay.
> >
> > And following on from my other conversation in this thread...  What
> > should/will be the specified behavior w.r.t. resetting or not
> > resetting the timer on a sched_yield()?
>
> I think I'll keep it as is; so sched_yield() will _not_ reset the
> counter. The rationale is that the process didn't actually stop running
> - it just got scheduled away.

Okay -- thanks.  I will make that clear in the man page.

Cheers,

Michael

-- 
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

RLIMIT_RTTIME documentation for getrlimit.2

[Michael Kerrisk]

Peter,

Below is the draft text that I will add to the getrlimit.2 man page to describe
RLIMIT_RTTIME.  Does it look okay to you?  (I will add a pointer in
sched_setscheduler.2 to this description in getrlimit.2.)

       RLIMIT_RTTIME (Since Linux 2.6.25)
              Specifies a limit on the amount of CPU time that a
              process  scheduled  under  a  real-time scheduling
              policy may consume without making a blocking  sys-
              tem  call.   For  the  purpose of this limit, each
              time a process makes a blocking system  call,  the
              count  of  its consumed CPU time is reset to zero.
              The CPU time count is not  reset  if  the  process
              continues  trying to use the CPU but is preempted,
              its   time   slice   expires,    or    it    calls
              sched_yield(2).

              Upon  reaching the soft limit, the process is sent
              a SIGXCPU  signal.   If  the  process  catches  or
              ignores  this  signal  and continues consuming CPU
              time, then SIGXCPU will  be  generated  once  each
              second  until  the hard limit is reached, at which
              point the process is sent a SIGKILL signal.

              The intended use of this limit is to stop  a  run-
              away real-time process from locking up the system.

Cheers,

Michael

Re: RLIMIT_RTTIME documentation for getrlimit.2

[Michael Kerrisk]

Hey Peter,

Ping!

Cheers,

Michael


---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages@googlemail.com>
Date: Fri, Apr 18, 2008 at 6:52 PM
Subject: RLIMIT_RTTIME documentation for getrlimit.2
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Eugene Teo <eugeneteo@kernel.sg>, linux-kernel@vger.kernel.org,
Neil Horman <nhorman@tuxdriver.com>, Ingo Molnar <mingo@elte.hu>,
linux-man@vger.kernel.org


Peter,

Below is the draft text that I will add to the getrlimit.2 man page to describe
RLIMIT_RTTIME.  Does it look okay to you?  (I will add a pointer in
sched_setscheduler.2 to this description in getrlimit.2.)

      RLIMIT_RTTIME (Since Linux 2.6.25)
             Specifies a limit on the amount of CPU time that a
             process  scheduled  under  a  real-time scheduling
             policy may consume without making a blocking  sys-
             tem  call.   For  the  purpose of this limit, each
             time a process makes a blocking system  call,  the
             count  of  its consumed CPU time is reset to zero.
             The CPU time count is not  reset  if  the  process
             continues  trying to use the CPU but is preempted,
             its   time   slice   expires,    or    it    calls
             sched_yield(2).

             Upon  reaching the soft limit, the process is sent
             a SIGXCPU  signal.   If  the  process  catches  or
             ignores  this  signal  and continues consuming CPU
             time, then SIGXCPU will  be  generated  once  each
             second  until  the hard limit is reached, at which
             point the process is sent a SIGKILL signal.

             The intended use of this limit is to stop  a  run-
             away real-time process from locking up the system.

Cheers,

Michael




-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html

Re: RLIMIT_RTTIME documentation for getrlimit.2

[Peter Zijlstra]

On Mon, 2008-04-28 at 13:44 +0200, Michael Kerrisk wrote:
> Hey Peter,
> 
> Ping!

Thanks for the reminder ;-)

> Cheers,
> 
> Michael
> 
> 
> ---------- Forwarded message ----------
> From: Michael Kerrisk <mtk.manpages@googlemail.com>
> Date: Fri, Apr 18, 2008 at 6:52 PM
> Subject: RLIMIT_RTTIME documentation for getrlimit.2
> To: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Eugene Teo <eugeneteo@kernel.sg>, linux-kernel@vger.kernel.org,
> Neil Horman <nhorman@tuxdriver.com>, Ingo Molnar <mingo@elte.hu>,
> linux-man@vger.kernel.org
> 
> 
> Peter,
> 
> Below is the draft text that I will add to the getrlimit.2 man page to describe
> RLIMIT_RTTIME.  Does it look okay to you?  (I will add a pointer in
> sched_setscheduler.2 to this description in getrlimit.2.)
> 
>       RLIMIT_RTTIME (Since Linux 2.6.25)
>              Specifies a limit on the amount of CPU time that a
>              process  scheduled  under  a  real-time scheduling
>              policy may consume without making a blocking  sys-
>              tem  call.   For  the  purpose of this limit, each
>              time a process makes a blocking system  call,  the
>              count  of  its consumed CPU time is reset to zero.
>              The CPU time count is not  reset  if  the  process
>              continues  trying to use the CPU but is preempted,
>              its   time   slice   expires,    or    it    calls
>              sched_yield(2).
> 
>              Upon  reaching the soft limit, the process is sent
>              a SIGXCPU  signal.   If  the  process  catches  or
>              ignores  this  signal  and continues consuming CPU
>              time, then SIGXCPU will  be  generated  once  each
>              second  until  the hard limit is reached, at which
>              point the process is sent a SIGKILL signal.
> 
>              The intended use of this limit is to stop  a  run-
>              away real-time process from locking up the system.

Looks excellent, thanks!

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

in so far that is applicable to man pages ;-)

Re: RLIMIT_RTTIME documentation for getrlimit.2

[Michael Kerrisk]

>  > Below is the draft text that I will add to the getrlimit.2 man page to describe
>  > RLIMIT_RTTIME.  Does it look okay to you?  (I will add a pointer in
>  > sched_setscheduler.2 to this description in getrlimit.2.)
>  >
>  >       RLIMIT_RTTIME (Since Linux 2.6.25)
>  >              Specifies a limit on the amount of CPU time that a
>  >              process  scheduled  under  a  real-time scheduling
>  >              policy may consume without making a blocking  sys-
>  >              tem  call.   For  the  purpose of this limit, each
>  >              time a process makes a blocking system  call,  the
>  >              count  of  its consumed CPU time is reset to zero.
>  >              The CPU time count is not  reset  if  the  process
>  >              continues  trying to use the CPU but is preempted,
>  >              its   time   slice   expires,    or    it    calls
>  >              sched_yield(2).
>  >
>  >              Upon  reaching the soft limit, the process is sent
>  >              a SIGXCPU  signal.   If  the  process  catches  or
>  >              ignores  this  signal  and continues consuming CPU
>  >              time, then SIGXCPU will  be  generated  once  each
>  >              second  until  the hard limit is reached, at which
>  >              point the process is sent a SIGKILL signal.
>  >
>  >              The intended use of this limit is to stop  a  run-
>  >              away real-time process from locking up the system.
>
>
> Looks excellent, thanks!

Good -- thanks for checking it over.

>  Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
>
>  in so far that is applicable to man pages ;-)

It works for me.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html