Date: Fri, 21 Dec 2001 09:07:05 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG, Peter Wemm <peter@wemm.org>, Luigi Rizzo <rizzo@aciri.org> Subject: Re: vm_zeropage priority problems. Message-ID: <XFMail.011221090705.jhb@FreeBSD.org> In-Reply-To: <20011222023741.P5064-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.011221090705.jhb>