From owner-freebsd-current Fri Dec 21 9:51: 9 2001 Delivered-To: freebsd-current@freebsd.org Received: from iguana.aciri.org (iguana.aciri.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id 11E2337B416; Fri, 21 Dec 2001 09:50:59 -0800 (PST) Received: (from rizzo@localhost) by iguana.aciri.org (8.11.3/8.11.1) id fBLHowu18046; Fri, 21 Dec 2001 09:50:58 -0800 (PST) (envelope-from rizzo) Date: Fri, 21 Dec 2001 09:50:58 -0800 From: Luigi Rizzo To: John Baldwin Cc: Bruce Evans , current@FreeBSD.org, Peter Wemm Subject: Re: vm_zeropage priority problems. Message-ID: <20011221095058.A17968@iguana.aciri.org> References: <20011222023741.P5064-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i 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 Don't know how interesting this can be, but i am writing (no plans to commit it, unless people find it interesting) some code to implement a weight-based instead of priority-based scheduler. The code is basically the WF2Q+ scheme which is already part of dummynet, adapted to processes. It is quite compact, and i think i can make it reasonably compatible with the old scheme, i.e. a sysctl var can be used to switch between one and the other with reasonably little overhead. This would help removing the ugly property that priority-based have, which is that one process can starve the rest of the system. cheers luigi On Fri, Dec 21, 2001 at 09:07:05AM -0800, John Baldwin wrote: ... > > 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