From owner-freebsd-current Fri Dec 21 5:46:45 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id D8CA237B419; Fri, 21 Dec 2001 05:46:42 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA06426; Sat, 22 Dec 2001 00:46:38 +1100 Date: Sat, 22 Dec 2001 00:46:40 +1100 (EST) From: Bruce Evans X-X-Sender: To: John Baldwin Cc: Luigi Rizzo , Peter Wemm , Subject: Re: vm_zeropage priority problems. In-Reply-To: Message-ID: <20011222003639.B4708-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 20 Dec 2001, John Baldwin wrote: > On 20-Dec-01 Luigi Rizzo wrote: > > On Thu, Dec 20, 2001 at 12:16:03PM -0800, John Baldwin wrote: > >> However, kthreads should tsleep() with their current priority, not PPAUSE. > > > > "current" meaning pri_level or pri_native ? What if one tries to > > tsleep() while holding a lock and so its pri_level is raised ? > > pri_level. Calling tsleep() while holding a lock is a bug though. :) Unless > you are calling msleep() with a lock that will be released. > > > In the device polling code i did a tsleep on the "original" pri_level, > > but maybe pri_native is good enough. > > pri_level is more correct. I think pri_native is just an implementation detail which shouldn't be used or visible to threads. It used used by the priority propagation mechanism to hold the original pri_level. Threads should just use their original priority (or a different one if they want to temporarily change thier priority). Even pri_level probably shouldn't be used or visible to threads. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message