From owner-freebsd-arch@FreeBSD.ORG Wed Sep 29 21:00:44 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAE4D16A4CE; Wed, 29 Sep 2004 21:00:44 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B34F43D58; Wed, 29 Sep 2004 21:00:43 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i8TL0aNl017870; Wed, 29 Sep 2004 17:00:36 -0400 (EDT) Date: Wed, 29 Sep 2004 17:00:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Julian Elischer In-Reply-To: <415B1DD9.2050409@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-arch@freebsd.org cc: David Xu cc: Stephan Uphoff Subject: Re: sched_userret priority adjustment patch for sched_4bsd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 21:00:45 -0000 On Wed, 29 Sep 2004, Julian Elischer wrote: > > > John Baldwin wrote: > > > > >That's ok. This discussion has been very fruitful on my end at least as > >talking this out has helped me get a much better grasp on how this stuff > >works on 4.x and should be done in 5.x to obtain at least somewhat similar > >behavior. > > > > > well if you've worked it out,.. do let the rest of us know :-) > > I do think that there are several points that need work.. > 1/ kse threads are ephemeral, and so they don't gather any 'history'. > therefore it needs to be gathered somewher eelse.. (e.g. the ksegrp, > but what does that actually mean?) > 2/ what if the kg has both long-running and interractive threads? > 3/ sibling thread affinity and how that affects priority and scheduling. > > > We COULD store information in the mailbox.. > but then we need to trust the user with it.. > So then where do we store it? > > I have considerrred a store of 'cached' and "hashed" (like the buffer > cache) sched-info structs that are recycled > in a least-recently used manner.. when you get a thread with a mailbox > you look for a sched-stats block > corresponding with that mailbox address and use it.. > if yu don't find it then you know that thread has not run for a long time.. > so you grab the least-recently used one and recycle it as that thread > hasn't run for a while. > Basically the kernel could keep stats on behalf of the most active KSE > threads in an efficient manner. > The small stats structs would need to be only about 8 words.. > (4 for 2 x doubel links. one for mailbox addr/key, and 3 for sched stats.) > In effect the kernel keeps tabs on the most active user threads without > the UTS knowing about it. Remember that the UTS (IAW POSIX) should be in charge of which threads run _within_ a process. Across processes, and for system scope threads, that's another story. I think it would be cool if the UTS could store its version of priority in the thread mailbox, and the kernel would use this as a hint for which threads should get worked on when blocked in the kernel. For instance, if a thread is currently running with high priority and it makes a system call, that's a chance for the kernel to continue other blocked threads. But if the other blocked threads are all of lower (UTS) priority, you might not want to continue them (or upcall) when the currently running thread has a higher priority. -- Dan Eischen