From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: RLIMIT_RTTIME documentation for getrlimit.2 Date: Mon, 28 Apr 2008 14:09:20 +0200 Message-ID: <1209384560.13978.9.camel@twins> References: <20080208145950.GA3910@kernel.sg> <1204212100.12120.9.camel@twins> <1207904485.7074.28.camel@twins> <1207905668.7074.32.camel@twins> <1207906325.7153.2.camel@twins> <4808D1CC.80103@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-man-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Michael Kerrisk Cc: Eugene Teo , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Neil Horman , Ingo Molnar , linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-man@vger.kernel.org On Mon, 2008-04-28 at 13:44 +0200, Michael Kerrisk wrote: > Hey Peter, > > Ping! Thanks for the reminder ;-) > Cheers, > > Michael > > > ---------- Forwarded message ---------- > From: Michael Kerrisk > Date: Fri, Apr 18, 2008 at 6:52 PM > Subject: RLIMIT_RTTIME documentation for getrlimit.2 > To: Peter Zijlstra > Cc: Eugene Teo , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, > Neil Horman , Ingo Molnar , > linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > > > Peter, > > Below is the draft text that I will add to the getrlimit.2 man page to describe > RLIMIT_RTTIME. Does it look okay to you? (I will add a pointer in > sched_setscheduler.2 to this description in getrlimit.2.) > > RLIMIT_RTTIME (Since Linux 2.6.25) > Specifies a limit on the amount of CPU time that a > process scheduled under a real-time scheduling > policy may consume without making a blocking sys- > tem call. For the purpose of this limit, each > time a process makes a blocking system call, the > count of its consumed CPU time is reset to zero. > The CPU time count is not reset if the process > continues trying to use the CPU but is preempted, > its time slice expires, or it calls > sched_yield(2). > > Upon reaching the soft limit, the process is sent > a SIGXCPU signal. If the process catches or > ignores this signal and continues consuming CPU > time, then SIGXCPU will be generated once each > second until the hard limit is reached, at which > point the process is sent a SIGKILL signal. > > The intended use of this limit is to stop a run- > away real-time process from locking up the system. Looks excellent, thanks! Acked-by: Peter Zijlstra in so far that is applicable to man pages ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html