Date: Mon, 9 Oct 2006 10:06:54 +0800 From: David Xu <davidxu@freebsd.org> To: freebsd-current@freebsd.org Cc: Attilio Rao <attilio@freebsd.org>, John-Mark Gurney <gurney_j@resnet.uoregon.edu>, Kip Macy <kmacy@fsmware.com>, Ivan Voras <ivoras@fer.hr> Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers Message-ID: <200610091006.54219.davidxu@freebsd.org> In-Reply-To: <20061008181618.N69745@demos.bsdclusters.com> References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <20061009002200.GM793@funkthat.com> <20061008181618.N69745@demos.bsdclusters.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610091006.54219.davidxu>