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

[Michael Kerrisk]

On 4/11/08, Michael Kerrisk <mtk.manpages@xxxxxxxxxxxxxx> wrote:
> On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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
--
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/