Date: Fri, 21 Dec 2001 09:50:58 -0800 From: Luigi Rizzo <rizzo@aciri.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.org, Peter Wemm <peter@wemm.org> Subject: Re: vm_zeropage priority problems. Message-ID: <20011221095058.A17968@iguana.aciri.org> In-Reply-To: <XFMail.011221090705.jhb@FreeBSD.org> References: <20011222023741.P5064-100000@gamplex.bde.org> <XFMail.011221090705.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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?20011221095058.A17968>