Date: Sun, 28 Nov 1999 08:41:57 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Arun Sharma <adsharma@sharmas.dhs.org> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911281641.IAA44909@apollo.backplane.com> References: <Pine.SUN.3.91.991124134533.26314A-100000@pcnet1.pcnet.com> <199911241905.LAA20045@apollo.backplane.com> <14396.15070.190669.25400@avalon.east> <199911241941.LAA20231@apollo.backplane.com> <19991124212521.W301@sturm.canonware.com> <199911280338.TAA40637@apollo.backplane.com> <19991127205752.A7145@sharmas.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:current BSD scheduler.
:
:(a) schedcpu() is called every hz ticks. This requires locking the runqueues.
: On a SMP system, all other processors are completely locked out. Clearly,
: someone needs to redesign the system such that priorities get recomputed
: in an event driven fashion. Uresh Vahalia's book (Ch 5.5.6) talks about
: this.
I think we are already operating under the assumption that the current
scheduler must be rewritten, or at least significantly modified. Amoung
other things we have to get rid of all the extra junk that is in assembler
that could easily be C (I seem to recall someone actually working towards
that goal, was any of that ever committed? It seemed pretty good).
Ideas have already been put forth. For example, giving the scheduler
its own lock (or locks) independant of the MP lock.
:(b) If you want to implement processor binding, the implementation is simpler
: with per cpu runqueues.
A multi-queue implementation would scale better for this situation.
I wouldn't go as far as to say that it would be necessarily easier from
an implementation point of view.
I think of it in these terms: You have a process which may have no
binding restrictions, loose binding restrictions, or hard binding
restrictions. Most of the thread support is going to be classified as
having loose binding restrictons or none at all (i.e. a general purpose
setup). Hard binding is easiest with multiple queues for obvious reasons,
but loose/no binding is easiest with a single queue. From an
implementation point of view.
:(c) Although not a justification by itself, I remember reading that the most
: recent version of AIX uses per cpu runqueues to scale better on SMP.
:
:On the other hand, implementing scheduler activations and SMP scaling
:simultaneously would be too much of a change. It might be a good idea
:to do one thing at a time.
:
: -Arun
I'm thinking that it would be easier to augment the single run queue we
currently have first and then redo it later after the rest of the system
has been made more SMP aware. In regards to performance, right now the
scheduler is the least of our worries.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199911281641.IAA44909>