Date: Wed, 9 Oct 2002 02:14:59 -0400 (EDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Julian Elischer <julian@elischer.org> Cc: arch@freebsd.org Subject: Re: Scheduler framework. Message-ID: <20021009020755.N44108-100000@mail.chesapeake.net> In-Reply-To: <Pine.BSF.4.21.0210082231390.37238-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Oct 2002, Julian Elischer wrote: > > 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. Yeah, I have some changes in proc.h that are a little messy. I'm going to have to figure out how to stuff scheduler dependant data in there. I don't caculate pctcpu right now. That's going to be my biggest problem with this I fear. > > > > > 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.. Yep. > > > 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. > Yes, I'm going to have to do that to complete the scheduler. For now I'm only implementing the KSE to cpu affinity. The rest can fall into place later. This will at least give us good processor affinity in the single threaded case. > > > > 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. I think that you should move other work onto the lightly loaded processor and not 2 KSEs from the same process onto the same processor. KSEs are what defines the parallelism of the application. Having two in the same kseg on the same processor defeats that. Do you have any plans to implement cpu binding? > > > > > 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. > Nope, I haven't looked into that. It sounds like it would just make performance a little worse by forcing a thread to temporarily migrate. 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?20021009020755.N44108-100000>