Date: Tue, 4 Mar 2003 02:57:07 -0500 From: Hiten Pandya <hiten@unixdaemons.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: Possible patch for limiting APs at startup Message-ID: <20030304075707.GA1802@unixdaemons.com> In-Reply-To: <XFMail.20030303144921.jhb@FreeBSD.org> References: <20030301200615.A63428@FreeBSD.org> <XFMail.20030303144921.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin (Mon, Mar 03, 2003 at 02:49:21PM -0500) wrote: > > On 02-Mar-2003 Juli Mallett wrote: > > * De: Hiten Pandya <hiten@unixdaemons.com> [ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030304075707.GA1802>