From owner-freebsd-current Mon Mar 3 23:57:11 2003 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 CE83E37B401; Mon, 3 Mar 2003 23:57:09 -0800 (PST) Received: from angelica.unixdaemons.com (angelica.unixdaemons.com [209.148.64.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7B5743F93; Mon, 3 Mar 2003 23:57:08 -0800 (PST) (envelope-from hiten@angelica.unixdaemons.com) Received: from angelica.unixdaemons.com (localhost.unixdaemons.com [127.0.0.1]) by angelica.unixdaemons.com (8.12.7/8.12.1) with ESMTP id h247v7jL002995; Tue, 4 Mar 2003 02:57:07 -0500 (EST) Received: (from hiten@localhost) by angelica.unixdaemons.com (8.12.7/8.12.1/Submit) id h247v7PL002994; Tue, 4 Mar 2003 02:57:07 -0500 (EST) (envelope-from hiten) Date: Tue, 4 Mar 2003 02:57:07 -0500 From: Hiten Pandya To: John Baldwin Cc: current@FreeBSD.org Subject: Re: Possible patch for limiting APs at startup Message-ID: <20030304075707.GA1802@unixdaemons.com> References: <20030301200615.A63428@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: FreeBSD i386 X-Public-Key: http://www.pittgoth.com/~hiten/pubkey.asc X-URL: http://www.unixdaemons.com/~hiten X-PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: > > On 02-Mar-2003 Juli Mallett wrote: > > * De: Hiten Pandya [ Data: 2003-03-01 ] > > [ Subjecte: Possible patch for limiting APs at startup ] > >> Hello. > >> > >> Just as the topic says, do you think this patch is good enough, or gets > >> even close to it? I have tested the patch, and it seems to do it's job > >> in the right way. Some might call it hackery, but it's better than > >> nothing I would suppose. > > > > I think your use of "cpus" to refer to APs only is silly, and also that > > overriding mp_naps instead of using a real cpus value and using it as > > a bounds check akin to MAXCPU, is a bit of the wrong direction. As you > > know, the following is my patch, and it does not work, but I think, > > personally, the behaviour is saner, in theory at least :) > > You should set mp_maxcpus prior to the mp_naps test so it isn't left > invalid in the common case. Also, this patch doesn't limit HT cpu's > at all. I could have a 4 cpu system with HTT and maxcpus=2, and I > will end up with 4 CPU's due to 2 logical CPU's per processor. Perhaps > this is intentional? Yes. It was intentional, in the sense that we only want to limit the number of Application Processors, and not the HTT cores inside it, because that does not make much sense, IMHO. Do you think that patch will be committed, or does it need improving? (http://www.unixdaemons.com/~hiten/work/diffs/mp_machdep.c.patch) Cheers. -- Hiten Pandya (hiten@unixdaemons.com, hiten@uk.FreeBSD.org) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message