From owner-freebsd-current Fri Dec 21 9: 7:56 2001 Delivered-To: freebsd-current@freebsd.org Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by hub.freebsd.org (Postfix) with ESMTP id 15F9F37B42B for ; Fri, 21 Dec 2001 09:07:23 -0800 (PST) Received: (qmail 8830 invoked from network); 21 Dec 2001 17:07:22 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Dec 2001 17:07:22 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011222023741.P5064-100000@gamplex.bde.org> Date: Fri, 21 Dec 2001 09:07:05 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: vm_zeropage priority problems. Cc: current@FreeBSD.ORG, Peter Wemm , Luigi Rizzo 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 21-Dec-01 Bruce Evans wrote: > On Fri, 21 Dec 2001, Luigi Rizzo wrote: > >> On Sat, Dec 22, 2001 at 12:46:40AM +1100, Bruce Evans wrote: >> > 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. >> >> the original priority should be somewhere and accessible, >> either directly or through some function. Otherwise how >> do we know what to pass to tsleep() ? > > It's whatever the thread set itself. There is no good way of setting > this either (vm_pagezero() and poll_idle() hack it into > td->td_ksegrp->kg_pri). Userland would use rtprio(2) instead. > Unfortunately, this gives priorities in different units than the ones > for tsleep(). pri_level is the current priority of the thread. The actual priority level is going to move back into the thread and out of the KSE group so that tsleep and priority propagation work properly, but pri_native, pri_user, and nice will stay in the KSE group. The "normal" priorities for tsleep() are just a subset of the priorities available to a thread. Thus, they are using the same unit, but perhaps a wider range. >> In any case I wonder if this is a bug new in -current; -stable >> uses three separate data structures for realtime, user and idle tasks >> so even specifying the wrong priority in tsleep should not cause >> crossing classes there. -current has only one array, hence the >> chance of doing the wrong thing. > > The 3 classes are a design bug in -stable. Crossing classes is sometimes > right and 3 classes mainly make it harder and force triplication of code. Agreed. In current we basically have one large priority array. At the top (low priorities) are realtime kernel priorities including interrupt thread priorities. Below those are other top-half kernel priorities including the normal sleep priorities. Below that are real-time user priorities, followed by time sharing user priorities, and finally idle user priorities. Possibly real-time user priorities should move up into the real-time kernel range, and it should be noted that the idle priorites are for idle kernel threads, not just user threads (so sys/priority.h may need a bit of updating). This is a simpler model esp. when you consider a thread of one priority class blocking on a lock held by a thread of a "lower" priority class as you only have to update pri_level for priority propagation rather than comparing classes and having to manage that extra gunk. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message