Date: Sun, 8 Oct 2006 19:10:51 -0700 (PDT) From: Kip Macy <kmacy@fsmware.com> To: David Xu <davidxu@freebsd.org> Cc: Attilio Rao <attilio@freebsd.org>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-current@freebsd.org, Ivan Voras <ivoras@fer.hr> Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers Message-ID: <20061008191021.B85399@demos.bsdclusters.com> In-Reply-To: <200610091006.54219.davidxu@freebsd.org> References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <20061009002200.GM793@funkthat.com> <20061008181618.N69745@demos.bsdclusters.com> <200610091006.54219.davidxu@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Oct 2006, David Xu wrote: > On Monday 09 October 2006 09:18, Kip Macy wrote: > > > Wouldn't having a single run queue lock still serialize the cpu's when > > > getting a thread to run? Don't we really need a per cpu run queue, and > > > then have a scheduler that puts threads on the cpu's run queues? > > > > Balancing run queues has overhead as well. From what I've seen having > > threads bouncing back and forth between the sleep queue and the run > > queue because sleep / wakeup is overused (see lockmgr) is a bigger deal > > right now. Moving to multiple run queues is inappropriate at this time. > > > > > > -Kip > > If single sched_lock is not removed, it even is not worthy of trying mutliple > run queues, since any time you spent under sched_lock will be scaled to > N times, where N is the number of CPU, in worst case. This makes load-balance > a bit useless. This is without sched_lock. -Kip
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061008191021.B85399>