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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1207905668.7074.32.camel@twins>
Date:	Fri, 11 Apr 2008 11:21:08 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Michael Kerrisk <mtk.manpages@...glemail.com>
Cc:	Michael Kerrisk <mtk.manpages@...il.com>,
	Eugene Teo <eugeneteo@...nel.sg>, linux-kernel@...r.kernel.org,
	Neil Horman <nhorman@...driver.com>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc/<pid>/limits

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@...llo.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@...llo.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/