From owner-freebsd-current Tue Mar 4 11:42:39 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 AC11A37B401 for ; Tue, 4 Mar 2003 11:42:37 -0800 (PST) Received: from mail.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA22543FAF for ; Tue, 4 Mar 2003 11:42:34 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 21485 invoked from network); 4 Mar 2003 19:42:40 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Mar 2003 19:42:40 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.6/8.12.6) with ESMTP id h24JdxhT045810; Tue, 4 Mar 2003 14:40:01 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20030304075707.GA1802@unixdaemons.com> Date: Tue, 04 Mar 2003 14:42:44 -0500 (EST) From: John Baldwin To: Hiten Pandya Subject: Re: Possible patch for limiting APs at startup Cc: current@FreeBSD.org 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 On 04-Mar-2003 Hiten Pandya wrote: > 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) Juli's patch is much closer. Setting mp_naps directly is bogus at best. mp_naps would get reset by the mptable stuff anyways since SI_SUB_CPU is well after SI_SUB_TUNABLES. Ignoring HTT is fine. All I would really do is change juli's patch to set the max value before the if test so it is always valid. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message