Date: Thu, 05 Jul 2001 08:35:43 -0700 From: Michael Williams <michaelw@IPRG.nokia.com> To: Henry Miller <hank@black-hole.com> Cc: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>, smp@FreeBSD.ORG Subject: Re: per cpu runqueues, cpu affinity and cpu binding. Message-ID: <3B44894F.BD90890F@iprg.nokia.com> References: <Pine.BSF.4.21.0107032151330.15604-100000@daphne.bogus>
next in thread | previous in thread | raw e-mail | index | archive | help
Yes, how about leaving the decisions on scheduling algorithms (including affinity) until later when the cost of thread/CPU switching is known (i.e. do the work to compute the cycle count.) Then iterate between development phases of improving the time+cache burden, and modifying the thread/process scheduling criterion. From Henry's point I glean that once switching gets to be a "significant" factor in the overall system load, the meaning of "fairness" could change. Regarding daemons, I think there are different classes of daemons. Because they are long lived doesn't really say much about their workload, working set, needs for scheduling, and priority versus other processes and daemons. Michael Henry Miller wrote: > On Mon, 2 Jul 2001, E.B. Dreger wrote: > > > > First of all, we have two different types of processor affinity. > > > 1. user specified CPU attachment, as you have implemented. > > > 2. system-wide transparent processor affinity, transparent > > > to all users, which I see some work below. > > > > Unless two processes are running on CPU #1, and CPU #2 becomes idle. > > Then switching a process to CPU #2 makes sense... unless the process > > getting switched is "close" to completion. > > > > I'll probably get flamed for suggesting something so ugly, but should we > > assume that non-daemon processes are short-running, and be more resistant > > to switching CPUs on those? > > Accually some OS theory says that the longer a process runs the lower > priority it should get. A simple extention says that if two process are > running "alot" and are on the same CPU, and there is an idle CPU, then we > should switch one process to the other CPU. > > Small tasks that can complete in just a few time slices should be run > quickly. Even with a load of 1000 on a sinlge CPU machine we should note > that those other processes have been running for a while and schedual the > new task more often for a few rounds, and drop the priority if it doesn't > complete "quickly". (This obviously doesn't apply for time/safety > critical threads) If we are even half way intellegent about schedualing > initial CPU, then there is no need to bother switching CPUs for the short > lived programs as they will exit before any benifit from switching CPUs > would show up. > > FreeBSD may already do some of that, I've not checked. > > A deamon isn't enough for everyone, on some servers it will be good, but > others it is the wrong thing. Povray for example is typically not run as > a deamon, and it typically will run long enough that intellegent CPU > switching will decrease the overall runtime. There are others. > > Of course I'm not offering to do the work, so whoever is going to gets to > decide if the above is worth the bother. I can think of situations where > it won't matter and situations where it will. If either is more then a > rarely encountered end case is an exercise left to the reader. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B44894F.BD90890F>