Date: Sat, 27 Nov 1999 20:57:52 -0800 From: Arun Sharma <adsharma@sharmas.dhs.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <19991127205752.A7145@sharmas.dhs.org> In-Reply-To: <199911280338.TAA40637@apollo.backplane.com>; from Matthew Dillon on Sat, Nov 27, 1999 at 07:38:52PM -0800 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 27, 1999 at 07:38:52PM -0800, Matthew Dillon wrote:
>
> hmm. A very interesting article. They could well be correct - certainly
> a single scheduling queue would become a problem if you have many
> processors. I don't think there would be much contention with 4-8 cpu's,
> at least not if we limit the lock to *just* the operation surrounding
> the addition and removal of the KSE (using Julian's terminology) from
> the queue. Also, this contention would *not* occur during a context
> switch, only when a task is scheduled and descheduled.
Locking of the runqueue is a problem, unless changes are made to the
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.
(b) If you want to implement processor binding, the implementation is simpler
with per cpu runqueues.
(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
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?19991127205752.A7145>