Date: Wed, 6 Mar 2002 14:54:35 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: John Baldwin <jhb@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Jeff Roberson <jeff@FreeBSD.org> Subject: RE: cvs commit: src/sys/sys smp.h src/sys/kern subr_smp.c src/sy Message-ID: <Pine.BSF.4.21.0203061448290.23706-100000@beppo> In-Reply-To: <XFMail.020306174322.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> If someone wants to make them virtual then they can do it I suppose. > However, that doesn't help if you ever want to support the notion of > removing and adding CPU's at runtime. You would still have to deal with > sparse ID's in that case, so maybe it's just better to not assume packed > ID's to begin with? Well, yes and no. There's two issues here. Yes, you should assume a sparse space. But it's also convenient to know that there's some bounded (less than 1000, e.g.) number of CPUs so you can do arrays sizes, etc. It would also be able to index conveniently off of some number related to the currently running CPU instead of going "I'm CPU-ID 0x7abcdefg..hmm. Now let me search my database so I can find the softc that corresponds to this....". I suppose I'm just stretching it a bit. It seems to me you want to know some tag that identifies a particular CPU so you can index into associated information- usually. Simple and short number ranges (0..MAXCPU) are good for that. Knowing the actual h/w ID of the CPU is usually a platform specific thingie- possibly necesary for context switch support, but also easily derivable from the PCPU info that you get after indexing off of the 'virtual' id. Your argument about removing/adding CPUs isn't germane to this, really. -matt 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?Pine.BSF.4.21.0203061448290.23706-100000>