LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk.manpages@gmail.com>
To: "Peter Zijlstra" <a.p.zijlstra@chello.nl>
Cc: "Michael Kerrisk" <mtk.manpages@googlemail.com>,
	"Eugene Teo" <eugeneteo@kernel.sg>,
	linux-kernel@vger.kernel.org,
	"Neil Horman" <nhorman@tuxdriver.com>,
	"Ingo Molnar" <mingo@elte.hu>
Subject: Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits
Date: Fri, 11 Apr 2008 10:01:30 +0200	[thread overview]
Message-ID: <517f3f820804110101n595fb901rae58da6badb64a55@mail.gmail.com> (raw)
In-Reply-To: <1207899930.7074.23.camel@twins>

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

  reply	other threads:[~2008-04-11  8:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08 14:59 Eugene Teo
2008-02-08 15:10 ` Peter Zijlstra
2008-02-28 15:12   ` Michael Kerrisk
2008-02-28 15:21     ` Peter Zijlstra
2008-02-28 15:44       ` Michael Kerrisk
2008-02-28 15:50         ` Peter Zijlstra
2008-04-11  7:38           ` Michael Kerrisk
2008-04-11  7:45             ` Peter Zijlstra
2008-04-11  8:01               ` Michael Kerrisk [this message]
2008-02-29 12:32       ` Neil Horman
2008-04-11  8:56       ` Michael Kerrisk
2008-04-11  9:01         ` Peter Zijlstra
2008-04-11  9:16           ` Michael Kerrisk
2008-04-11  9:21             ` Peter Zijlstra
2008-04-11  9:27               ` Michael Kerrisk
2008-04-11  9:32                 ` Peter Zijlstra
2008-04-11  9:38                   ` Michael Kerrisk
2008-04-18 16:52                     ` RLIMIT_RTTIME documentation for getrlimit.2 Michael Kerrisk
2008-04-28 11:44                       ` Michael Kerrisk
2008-04-28 12:09                         ` Peter Zijlstra
2008-04-28 12:14                           ` Michael Kerrisk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=517f3f820804110101n595fb901rae58da6badb64a55@mail.gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=eugeneteo@kernel.sg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtk.manpages@googlemail.com \
    --cc=nhorman@tuxdriver.com \
    --subject='Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).