Messages in this thread | | | Subject | Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits | From | Peter Zijlstra <> | Date | Fri, 11 Apr 2008 09:45:30 +0200 |
| |
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.
| |