Date: Wed, 18 Jul 2001 13:52:23 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: smp@freebsd.org, audit@freebsd.org Subject: Re: planned change to mbinit code and minor changes to mp startup Message-ID: <Pine.BSF.4.21.0107181345420.49672-100000@beppo> In-Reply-To: <20010718104232.A96785@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 18 Jul 2001, Bosko Milekic wrote: > > Hi Matthew, > > Thanks for looking into this. It is clearly a problem. The proposed > solution is also good. However, it poses a problem when it comes to > netstat(1) and systat(1). They both presently rely on mp_ncpus and fetch > the PCPU stats treating the whole thing as a dense array. This isn't your > fault (it's mine), and I'd ask for this patch to sit pending for a while > until I get to cleaning up some of systat(1) and netstat(1) again (when I > re-enable mbtypes stats). It's relatively high on the TODO and I should be > there soon, so just bear with me as I re-settle in. The only thing that is really directly hanging up for me on this is to make support for the Alpha 8X00s work again (booting cpu is ID 8). I'd like to check the changes back in to support that, but there's no great overriding hurry on this. It's also true that the alternative to all of this is that 'cpuid' should in fact be considered a virtual construct. There's nothing that says that the Nth platform that FreeBSD is ported to programmatically identifies each specific CPU with a completely arbitrary 32 bit value. It's still fair to say that NCPU (defined at 32 or whatever) is a fair way to establish the overall upper limit. So, I'm still back a bit on the fence over whether or not I shouldn't just try and fix the alpha port to have cpuid be virtual and mp_ncpus be dense- at least until the spinup/spindown stuff is worked out. Now that you're back from vacation and agree that this is an issue that needs to be solved, I feel confident that you'll be able to do the right thing relatively soon. > On Sat, Jul 14, 2001 at 11:25:46AM -0700, Matthew Jacob wrote: > > > > Problem: the MB init and alloc code assumes that in the SMP case that there is > > a dense array of CPU ids for the CPUs present and reported via mp_ncpus. > [...] > > As for moving toward the (c) point you mention: I wonder how > reasonable it would be to offer (a) hook(s) to subsystems which they can > use to configure PCPU-specific intialization routines to be called when a > processor is enabled during runtime. i.e.: > > time 1: > CPU 1 off; > CPU 2 off; > CPU 3 on; > CPU 4 on; > > time 2: > CPU 1 off -> on; hook_for_cpu1(); > CPU 2 off -> on; hook_for_cpu2(); > CPU 3 on; > CPU 4 on; > > The hook functions could include, amongst other things, the code to > malloc() the necessary structures for the relevant per-CPU container. These are desirable. I just don't myself know the cleanest way to implement this. Or I could propose something, but as soon as that happens, a bunch of people who clearly know better while point out the deficiencies. It'd be nice if we skip this interim step and ask them to write it to begin with. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0107181345420.49672-100000>