LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.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 11:21:08 +0200	[thread overview]
Message-ID: <1207905668.7074.32.camel@twins> (raw)
In-Reply-To: <cfd18e0f0804110216l3c679bb6ned83f5d58d1c9d66@mail.gmail.com>

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.


  reply	other threads:[~2008-04-11  9:21 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
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 [this message]
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=1207905668.7074.32.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=eugeneteo@kernel.sg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtk.manpages@gmail.com \
    --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).