From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758827AbYDKHiT (ORCPT ); Fri, 11 Apr 2008 03:38:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757394AbYDKHiL (ORCPT ); Fri, 11 Apr 2008 03:38:11 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]:10196 "EHLO wa-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755294AbYDKHiK (ORCPT ); Fri, 11 Apr 2008 03:38:10 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a0Gnd6rFW5dvEAaz6Zb72+aaWKZDsvG8SP0f6hYA4jxULdU1XJgHqC1nmhQR9HfTAuebhQQqzjOvHFNopjhj/uUedNtD79+G1+T3k38JjSgkqXedA/hrEO4nLM1jiVqN8y3FxKO+sTBTZu4OmCKVYEeWshQXTg1SVOpfjr2Vl3A= Message-ID: Date: Fri, 11 Apr 2008 09:38:09 +0200 From: "Michael Kerrisk" To: "Peter Zijlstra" Subject: Re: [PATCH] proc: Add RLIMIT_RTTIME to /proc//limits Cc: "Michael Kerrisk" , "Eugene Teo" , linux-kernel@vger.kernel.org, "Neil Horman" , "Ingo Molnar" In-Reply-To: <1204213821.12120.15.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080208145950.GA3910@kernel.sg> <1202483445.6292.1.camel@lappy> <517f3f820802280712o3d756b4fq46461b226515e1f2@mail.gmail.com> <1204212100.12120.9.camel@twins> <1204213821.12120.15.camel@twins> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 28, 2008 at 5:50 PM, Peter Zijlstra wrote: > > On Thu, 2008-02-28 at 16:44 +0100, Michael Kerrisk wrote: > > Peter, > > > > Thanks for the text. > > > > On Thu, Feb 28, 2008 at 4:21 PM, Peter Zijlstra 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. > > > > Just to clarify: sleep here means a call to some blocking syscall > > (e.g., nanosleep(), read(), select(), etc.), right? Is there anything > > else that falls under the category of "sleep"? What about a call to > > sched_yield() where the process explicitly lets go of the CPU? > > Yes, and yes, others would be blocking on futexes and the like. Peter, 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? Cheers, Michael -- Michael Kerrisk Maintainer of the Linux man-pages project http://www.kernel.org/doc/man-pages/ Want to report a man-pages bug? Look here: http://www.kernel.org/doc/man-pages/reporting_bugs.html