Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Jan 2008 02:45:46 -0700 (MST)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        brde@optusnet.com.au
Cc:        rrs@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, jhb@FreeBSD.org, cvs-src@FreeBSD.org
Subject:   Re: cvs commit: src/sys/netinet sctp_bsd_addr.c
Message-ID:  <20080101.024546.1079618522.imp@bsdimp.com>
In-Reply-To: <20080101161858.A10345@delplex.bde.org>
References:  <200712311219.08286.jhb@freebsd.org> <20071231.203720.1306324107.imp@bsdimp.com> <20080101161858.A10345@delplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20080101161858.A10345@delplex.bde.org>
            Bruce Evans <brde@optusnet.com.au> writes:
: On Mon, 31 Dec 2007, M. Warner Losh wrote:
: 
: > In message: <200712311219.08286.jhb@freebsd.org>
: >            John Baldwin <jhb@FreeBSD.org> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080101.024546.1079618522.imp>