Date: Sat, 16 Mar 2002 20:26:31 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: John Baldwin <jhb@FreeBSD.org> Cc: Michael Smith <msmith@FreeBSD.org>, <cvs-all@FreeBSD.org>, <cvs-committers@FreeBSD.org>, Jeff Roberson <jeff@FreeBSD.org>, Doug Rabson <dfr@nlsystems.com> Subject: Re: cvs commit: src/sys/sys smp.h src/sys/kern subr_smp.c src/sy Message-ID: <20020316202408.O44076-100000@mail.chesapeake.net> In-Reply-To: <XFMail.020311120545.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 11 Mar 2002, John Baldwin wrote: > On 10-Mar-02 Michael Smith wrote: > >> > This screws up the SMP probe for ia64 because the information which > >> > cpu_mp_probe() uses isn't available until after cpu_startup() is called > >> > (i.e. SI_SUB_CPU:SI_ORDER_FIRST). The code in the ia64 platform which > >> > detects SMP can't (currently) run before the VM system is started... > > In many cases (IA64 is one of them), CPUs other than the boot processor > > may be detected and started up at any time. You want a constant that > > allows the maximum number of CPUs supported by the platform, rather than > > to detect the number of CPUs currently on the platform; just pick a sane > > upper bound (eg. 8) and work with it for now. > > MAXCPU does this. I agree that I would like to depend on this and > CPU_ABSENT() rather than on cpu_maxid. Even when using cpu_maxid, > you still need to use CPU_ABSENT to account for sparseness. > I am using CPU_ABSENT. On archs where mp_maxid makes sense early on in the boot process we should use it. Where it does not make sense we can set it to MAXCPU. The memory savings are well worth it, especially since MAXCPU is set to 32 on alpha. Any objections to this? I think it satisfies both sides. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020316202408.O44076-100000>