Date: Sun, 8 Oct 2006 18:18:16 -0700 (PDT) From: Kip Macy <kmacy@fsmware.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: Attilio Rao <attilio@freebsd.org>, freebsd-current@freebsd.org, David Xu <davidxu@freebsd.org>, Ivan Voras <ivoras@fer.hr> Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers Message-ID: <20061008181618.N69745@demos.bsdclusters.com> In-Reply-To: <20061009002200.GM793@funkthat.com> References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <20061008135031.G83537@demos.bsdclusters.com> <4529667D.8070108@fer.hr> <200610090634.31297.davidxu@freebsd.org> <20061008225150.GK793@funkthat.com> <3bbf2fe10610081555r67265368sf7f12edbf35bff0d@mail.gmail.com> <20061008155817.G29803@demos.bsdclusters.com> <20061009002200.GM793@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061008181618.N69745>