Skip to contentSkip to conversation

proc: Add RLIMIT_RTTIME to /proc/<pid>/limits

PATCH In review Eugene Teo 5 participants 21 messages Feb 8, 2008 – Apr 28, 2008

Subsystems (2)
Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7 Proc filesystem
lore
Share & tools
lore

Eugene Teo

author
#0 lore raw

PATCH 1/1 proc: Add RLIMIT_RTTIME to /proc/<pid>/limits

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 <[email protected]>
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +1 -0
index c59852b..dcf7be8 100644
@@ -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 */
Acked-by on v1 1/1
#1 lore raw
Quoted 3 lines · 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.

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

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Quoted 16 lines
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +1 -0
index c59852b..dcf7be8 100644
@@ -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 */
#2 lore raw

Peter,

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

Cheers,

Michael

Quoted 36 lines · Peter Zijlstra
Quoted 3 lines · 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.

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

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Quoted 9 lines
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +0 -0
index c59852b..dcf7be8 100644

fs/proc/base.c static const struct limit_names lnames[RLIM_NLIMITS] = { · line 418

Quoted 7 lines
fs/proc/base.c +1 -0
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 1 line
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com
#3 lore raw
Quoted 4 lines · Michael Kerrisk

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

Quoted 44 lines

Cheers,

Michael

Quoted 36 lines · Peter Zijlstra
Quoted 3 lines · 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.

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

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Quoted 9 lines
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +0 -0
index c59852b..dcf7be8 100644

fs/proc/base.c static const struct limit_names lnames[RLIM_NLIMITS] = { · line 418

Quoted 7 lines
fs/proc/base.c +1 -0
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#4 lore raw

Peter,

Thanks for the text.

Quoted 11 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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

Quoted 53 lines

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

Quoted 44 lines

Cheers,

Michael

Quoted 36 lines · Peter Zijlstra
Quoted 3 lines · 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.

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

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Quoted 9 lines
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +0 -0
index c59852b..dcf7be8 100644

fs/proc/base.c static const struct limit_names lnames[RLIM_NLIMITS] = { · line 418

Quoted 7 lines
fs/proc/base.c +1 -0
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 5 lines
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
#5 lore raw
Quoted 17 lines · Michael Kerrisk

Peter,

Thanks for the text.

Quoted 11 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 2 lines

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

#6 lore raw
Quoted 19 lines · Peter Zijlstra
Quoted 17 lines · Michael Kerrisk

Peter,

Thanks for the text.

Quoted 11 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 6 lines
Quoted 4 lines

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

Signature · 5 lines
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
#7 lore raw
Quoted 29 lines · Michael Kerrisk
Quoted 19 lines · Peter Zijlstra
Quoted 17 lines · Michael Kerrisk

Peter,

Thanks for the text.

Quoted 11 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 6 lines
Quoted 4 lines

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,

Quoted 7 lines

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.

#8 lore raw
Quoted 3 lines · Michael Kerrisk
Quoted 2 lines · Peter Zijlstra

On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote:

[...]

Quoted 9 lines
Quoted 7 lines

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?

Quoted 7 lines

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

Signature · 1 line
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com
Acked-by
#9 lore raw
In reply to Peter Zijlstra
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 21 lines

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

Quoted 16 lines

Cheers,

Michael

Quoted 11 lines · Peter Zijlstra
Quoted 3 lines · 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.

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

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Acked-by Neil Horman <[email protected]>
Signature · 4 lines
/****************************************************
 * Neil Horman <[email protected]>
 * Software Engineer, Red Hat
 ****************************************************/
#10 lore raw
In reply to Peter Zijlstra
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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

Quoted 42 lines
Quoted 40 lines · Peter Zijlstra
Quoted 36 lines · Eugene Teo
Quoted 3 lines

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!

Quoted 1 line
Signed-off-by Eugene Teo <[email protected]>
Acked-by Peter Zijlstra <[email protected]>
Quoted 9 lines
---
 fs/proc/base.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
fs/proc/base.c +0 -0
index c59852b..dcf7be8 100644

fs/proc/base.c static const struct limit_names lnames[RLIM_NLIMITS] = { · line 418

Quoted 7 lines
fs/proc/base.c +1 -0
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 5 lines
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
#11 lore raw
Quoted 26 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 1 line

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.

#12 lore raw
Quoted 27 lines · Peter Zijlstra
Quoted 26 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 8 lines
Quoted 1 line

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?

Signature · 5 lines
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
#13 lore raw
Quoted 30 lines · Michael Kerrisk
Quoted 29 lines · Peter Zijlstra
Quoted 27 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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?

Quoted 8 lines
Quoted 6 lines

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.

#14 lore raw
Quoted 37 lines · Peter Zijlstra
Quoted 35 lines · Michael Kerrisk
Quoted 34 lines · Peter Zijlstra
Quoted 26 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 5 lines
Quoted 3 lines
Quoted 1 line

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?

Quoted 3 lines

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

Signature · 5 lines
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
#15 lore raw
Quoted 38 lines · Michael Kerrisk
Quoted 37 lines · Peter Zijlstra
Quoted 35 lines · Michael Kerrisk
Quoted 34 lines · Peter Zijlstra
Quoted 26 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 9 lines
Quoted 3 lines

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.

#16 lore raw
Quoted 58 lines · Peter Zijlstra
Quoted 38 lines · Michael Kerrisk
Quoted 37 lines · Peter Zijlstra
Quoted 35 lines · Michael Kerrisk
Quoted 34 lines · Peter Zijlstra
Quoted 26 lines · Michael Kerrisk
Quoted 12 lines · Peter Zijlstra
Quoted 4 lines · Michael Kerrisk

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line

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.

Quoted 6 lines
Quoted 3 lines

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

Okay.

Quoted 7 lines
Quoted 3 lines

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

Signature · 5 lines
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
#17 lore raw

RLIMIT_RTTIME documentation for getrlimit.2

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

#18 lore raw

Re: RLIMIT_RTTIME documentation for getrlimit.2

Hey Peter,

Ping!

Cheers,

Michael

---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages-gM/[email protected]>
Date: Fri, Apr 18, 2008 at 6:52 PM
Subject: RLIMIT_RTTIME documentation for getrlimit.2
To: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/[email protected]>
Cc: Eugene Teo <[email protected]>, [email protected], Neil Horman <[email protected]>, Ingo Molnar <[email protected]>, [email protected]

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

Signature · 7 lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Acked-by
#19 lore raw

Re: RLIMIT_RTTIME documentation for getrlimit.2

Quoted 3 lines · Michael Kerrisk

Hey Peter,

Ping!

Thanks for the reminder ;-)

Quoted 40 lines

Cheers,

Michael

---------- Forwarded message ----------
From: Michael Kerrisk <mtk.manpages-gM/[email protected]>
Date: Fri, Apr 18, 2008 at 6:52 PM
Subject: RLIMIT_RTTIME documentation for getrlimit.2
To: Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/[email protected]>
Cc: Eugene Teo <[email protected]>, [email protected], Neil Horman <[email protected]>, Ingo Molnar <[email protected]>, [email protected]

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.

Quoted 2 lines

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-/NLkJaSkS4VmR6Xm/[email protected]>

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

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#20 lore raw

Re: RLIMIT_RTTIME documentation for getrlimit.2

Quoted 23 lines
Quoted 23 lines

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.

Quoted 5 lines
Quoted 2 lines

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.

Quoted 3 lines
Acked-by Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/[email protected]>

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

It works for me.

Cheers,

Michael

Signature · 7 lines
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
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html