From owner-freebsd-current@FreeBSD.ORG Mon Oct 9 02:10:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C882416A40F; Mon, 9 Oct 2006 02:10:54 +0000 (UTC) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos.bsdclusters.com [69.55.225.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736E543D46; Mon, 9 Oct 2006 02:10:54 +0000 (GMT) (envelope-from kmacy@fsmware.com) Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id k992AqlZ085455; Sun, 8 Oct 2006 19:10:52 -0700 (PDT) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id k992Aq7E085452; Sun, 8 Oct 2006 19:10:52 -0700 (PDT) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Sun, 8 Oct 2006 19:10:51 -0700 (PDT) From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: David Xu In-Reply-To: <200610091006.54219.davidxu@freebsd.org> Message-ID: <20061008191021.B85399@demos.bsdclusters.com> References: <2fd864e0610080423q7ba6bdeal656a223e662a5d@mail.gmail.com> <20061009002200.GM793@funkthat.com> <20061008181618.N69745@demos.bsdclusters.com> <200610091006.54219.davidxu@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Attilio Rao , John-Mark Gurney , freebsd-current@freebsd.org, Ivan Voras Subject: Re: [PATCH] MAXCPU alterable in kernel config - needs testers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2006 02:10:54 -0000 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