From owner-freebsd-arch Tue Oct 8 20:22:33 2002 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 60FA637B401 for ; Tue, 8 Oct 2002 20:22:31 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE32443E3B for ; Tue, 8 Oct 2002 20:22:30 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id g993MRO59995; Tue, 8 Oct 2002 23:22:27 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 8 Oct 2002 23:22:27 -0400 (EDT) From: Jeff Roberson To: Julian Elischer Cc: arch@freebsd.org Subject: Re: Scheduler framework. In-Reply-To: Message-ID: <20021008231137.O44108-100000@mail.chesapeake.net> 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 Tue, 8 Oct 2002, Julian Elischer wrote: > > More work needs to be done to modularise the scheduler. > KSE is making this more difficult but is also making it more necessary. > People can no-longer read it usn "understand it" in order to > tweek it for expereimentation.. > it needs to eb mor emodular so that people > can just throw it away and replace it.. > (e.g. what Luigi is up to). Yes, I agree, It seems to be getting closer though. The only way to really nail down the api is to look at the requirements of a few schedulers and implement it in a way that satisfies them all. > > BTW sorry, I just checked in a bunch of KSE changes that may > collide a bit with your patch.. probably you'll have some merging to do. > No worries. > > > yeah I noticed.. where is it? how does it cope with threads vs > Processes? I will post it soon. It's similar to the solaris/linux schedulers with a few exceptions. The base user priority is still assigned to the kseg, as is the fixed nice value. The kseg also records how many ticks each of it's kse's have slept for voluntarily. This value is decayed for every tick that they are awake. It is used to determine the interactivity and dynamic priority of the kseg. Each thread inherits a priority from it's kesg and that priority is adjusted as it enters/exits the kernel and through priority inheritance. Threads should eventually be bound to kse's and only migrated if a kse is starved. THis is essential for KSE to cpu affinity. KSEs get a time slice that is determined by the kseg's priority and interactivity. When this time slice expires the priority and new slice is calculated based on the behavior of all kses in the group. KSEs are bound to a particular cpu and are only migrated when one cpu's load is way out of balance. There are per cpu run queues, but there is still only one global sched lock. I did this for simplicity's sake. It's too late in 5.0 to risk complications such as that. This also makes migration a no brainer. It is, O(1) as well. That seems to be quite fashionable these days. > > Can we have a 'rough outline" here on -arch of your ideas? Well, the API in sched.h pretty much says it all. It's intended to be as minimal as possible. I hooked all the places that a scheduler might be interested in adjusting priorities and turned that into an api. Much of that was just figuring out where my scheduler and the old scheduler wanted to do different things. > > (BTW where are you?) > Seattle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message