Date: Tue, 8 Oct 2002 22:44:29 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: Scheduler framework. Message-ID: <Pine.BSF.4.21.0210082231390.37238-100000@InterJet.elischer.org> In-Reply-To: <20021008231137.O44108-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Oct 2002, Jeff Roberson wrote: > 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. fair enough... we are presently keeping some of this in the kse and some in the ksegrp. > > Each thread inherits a priority from it's kesg and that priority is > adjusted as it enters/exits the kernel and through priority inheritance. that's basically what we do now.. > Threads should eventually be bound to kse's and only migrated if a kse is > starved. THis is essential for KSE to cpu affinity. That's basically the plan, but it's rather a complicated scenario. Presently KSEs are the vehicle via which threads are scheduled, thereby stopping a process with a lot of threads from swamping the run queues. Currently there is no binding between threads (unless they are specifically bound) and KSEs and between KSEs and CPUs, It was envisionned that at some time in the future some 'affinity' would be added. > > 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. I was thinking about that.. my thought was that there is litle point in moving a KSE to a processor that already has a KSE from that group. just migrate the threads to the KSE that is on the processor that has time.. However Since then I have decided that in a heavily loaded system, it may be worth shifting 2 KSEs to the same processor if it has other work and neither would run for 50% anyhow. > > 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. Have you taken into account the KSE loaning that just went into the tree in the last week..? It's needed to stop deadlocks and starvation in some common cases. > > > > > (BTW where are you?) > > > Seattle > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0210082231390.37238-100000>