From owner-cvs-src@FreeBSD.ORG Tue Jan 1 17:50:41 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9650116A473; Tue, 1 Jan 2008 17:50:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 450E313C461; Tue, 1 Jan 2008 17:50:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id m01HnS2r035853; Tue, 1 Jan 2008 10:49:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 01 Jan 2008 10:49:34 -0700 (MST) Message-Id: <20080101.104934.1346822828.imp@bsdimp.com> To: rrs@cisco.com From: "M. Warner Losh" In-Reply-To: <477A2D6D.9030403@cisco.com> References: <20080101161858.A10345@delplex.bde.org> <20080101.024546.1079618522.imp@bsdimp.com> <477A2D6D.9030403@cisco.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: cvs-all@FreeBSD.org, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, jhb@FreeBSD.org, brde@optusnet.com.au Subject: Re: cvs commit: src/sys/netinet sctp_bsd_addr.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2008 17:50:41 -0000 In message: <477A2D6D.9030403@cisco.com> Randall Stewart writes: : M. Warner Losh wrote: : > In message: <20080101161858.A10345@delplex.bde.org> : > Bruce Evans writes: : > : On Mon, 31 Dec 2007, M. Warner Losh wrote: : > : : > : > In message: <200712311219.08286.jhb@freebsd.org> : > : > John Baldwin writes: : > : : > : > : The more correct fix though is to do a 'sched_prio()' at the start of the : > : > : thread's main loop to set the priority and then not adjust it via msleep(). : > : > : Kernel threads really should never pass a priority to msleep() but always '0' : > : > : (which means "don't change my priority"). : > : > : > : > Not PZERO? When should one use PZERO and when should one use a bare : > : > '0'? Can this information be added to the man page? : > : : > : PZERO is compatibility cruft which should never be used. Just a few : > : places in kern still use it to invent a priority when no suitable : > : priority (like PSOCK or PRIBIO) is already #defined. It isn't clear : > : where these invented priorities are suitable. : > : > Do we want to document the other Pxxxx priorities? : > : > : Otherwise, PZERO has a completely different meaning from either priority : > : 0 (maximal) or the bare 0 arg to msleep. It means some middle priority, : > : or the bias from priority 0 to get to that middle priority, so that : > : after subtracting it, 0 becomes the middle priority. The bare 0 is : > : actualy priority 0 (maximal) overloaded to mean "don't change the : > : priority". This overloading doesn't lose anything except clarity since : > : nothing is permitted to wake up at maximal priority after a sleep. : > : (Maximal priority is reserved for realtime priority ithreads and even : > : much lower priority ithreads are not permitted to sleep, and non-interrupt : > : threads aren't permitted to run at ithread priorities except temporarily : > : for priority propagation.) : > : > So would the following be a reasonable change to sleep.9? : > : > Index: sleep.9 : > =================================================================== : > RCS file: /home/ncvs/src/share/man/man9/sleep.9,v : > retrieving revision 1.61 : > diff -u -r1.61 sleep.9 : > --- sleep.9 30 Mar 2007 18:07:26 -0000 1.61 : > +++ sleep.9 1 Jan 2008 09:44:01 -0000 : > @@ -93,6 +93,10 @@ : > runnable with the specified : > .Fa priority : > when it resumes. : > +.Dv PZERO : > +should never be used, as it is for compatibility only. : > +A new priority of 0 means to use the thread's current priority when : > +it is made runnable again. : > If : > .Fa priority : > includes the : > : > Warner : > : That sure would have been nice to read in the manual page .. I would : have not changed this at all if I would have had that to read :-( : : I was pinged on xchat over an issue where the sctp worker thread : was hanging... and in the process I was told that 0 was max : priority.. which really concerned me... 0 having a special : meaning of.. "don't change my priority" means the old code : was fine :-0 : : Not that having a mid-range lower priority is a bad thing : for this task... I had someone point out that I wasn't using PZERO in the code I wrote at work, so I went through and changed all the drivers there to use PZERO always. The fact it is compatibility shimming wasn't clear at all, hence my desire to document it :0 Warner