Date: Wed, 10 Jan 2001 15:53:58 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> Cc: Jake Burkholder <jake@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Bruce Evans <bde@zeta.org.au> Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c machdep.c mp_mac Message-ID: <XFMail.010110155358.jhb@FreeBSD.org> In-Reply-To: <Pine.LNX.4.10.10101102158040.1951-100000@linux.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Jan-01 Gérard Roudier wrote: > > On Wed, 10 Jan 2001, John Baldwin wrote: >> There is nothign wrong with MI code knowing that it is running on a >> SMP-aware >> kernel. SMP is something that shouldn't be grafted into the side of the >> kernel, it is something it should be fully aware of. The locking >> requirements > > Per-cpu variables donnot bite us this more in SMP than in UP, as opposed > to shared variables. Godzilling stuff that accesses to these variables > looks like paranoia to me. If it is intended to apply the same approach to > shared variables, the SMP-over-aware kernel code would well resemble > rather Cobol than C code. ;-) No, shared variables are just variables. Here is the problem. There is no 'curproc' variable. There is a gd_curproc member of a struct globaldata, and each CPU has a struct globaldata tied to it. We can obtain it via PCPU_GET(curproc), or set it via PCPU_SET(curproc, myproc). Having a 'curproc' "magic" variable that doesn't exist that we assume we can read and write to like any other variable is a lot more hokie than admitting that we are accessing a special variable in a special way. >> are different for per-cpu variables than for global ones for example. (Most >> per-cpu variables don't need locking since they aren't contended, as opposed >> to >> shared variables.) The macros can be made more efficient for the common >> case >> (in fact, Jake already has it done) but that is an optimization that can be >> done later. For now let's focus on getting this working right and worry >> about >> optimization later. > > You seem to have been notified that you started with an immediate > pessimization. Only on the 386 UP case are these macros a pessimization. In fact, if you look at the old code, all these macros already existed, they just weren't used. (Instead we #define'd things liek curproc to GLOBAL_LVALUE_NV(curproc) and other weirdness). Also, Jake has another version of these macros that is more optimized that doesn't have the extra indirection. However, there is a growing problem here that I want to state so that everyone doesn't jump up and down every time we add a clock cycle somewhere: Let's get it _right_ first, and optimize later. Please, with the current state of -current (as many of you should be well aware, you certainly complain about it enough) getting things working correctly is _much_ more important than making our machines panic 1us faster than they do now. Ok? Come on, we knew we were going to be making lots of changes with this stuff, let's get it right first. The bigger gains in performance are going to be in the increased parallelism and in reworking algorithms to be more efficient. Micro-optimizations can be done _last_. I would much rather 5.0 be stable and a bit slower than something that is rip-roaring fast but can't make it through a make world w/o panic'ing. Some of the upcoming changes are going to really turn the kernel on its head. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010110155358.jhb>