From owner-freebsd-arch Thu Sep 20 14:52:35 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id BEE1437B40E; Thu, 20 Sep 2001 14:52:31 -0700 (PDT) Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id PAA33236; Thu, 20 Sep 2001 15:30:58 -0700 (PDT) Date: Thu, 20 Sep 2001 15:30:57 -0700 (PDT) From: Julian Elischer To: John Baldwin Cc: arch@freebsd.org, julian@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_mutex.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@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 Sep 2001, John Baldwin wrote: > > On 20-Sep-01 Julian Elischer wrote: > > > It is of course possible that what thread is running is not > > so important as whether the kse is running. What we need to decide > > is exactly what happens with proiority chages that are given to a thread.. > > does the KSE get it for the entire tick? for just the time that > > thread > > (syscall) > > is running? > > priority scope is something we have not really discussed yet. > > Nah, the thread holds the lock, so it is the thread's priority which must be > bumped. In this sense, bumping the kse group priority is wrong. Qutie > possibly what should happen is that the the pri_native and pri_user priorities > should be in the ksegroup but that the actual priority should be in the thread > since priority propagation just wants to ensure that the thread holding a > resource we need will run soon. If other threads from the same ksegroup run > first that doesn't really help. This is all uncharter water... Some of the possibilities are: 1/ Actual priority is boosted to that of teh thread when the thread is run 2/ The KSE priority is boosted to the priority of the highest priority thread assigned to it.. (for the entire tick, or until it enters user space.) 3/ The kse orders the threads to run in priority order, and reduces it's own priority each time it runs a new thread.. (losing it's tick if it reduces it below the priority of another KSE wanting to run..) 4/ Other ideas acceptable > > -- > > John Baldwin -- http://www.FreeBSD.org/~jhb/ > PGP Key: http://www.baldwin.cx/~john/pgpkey.asc > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message