Date: Thu, 11 Jan 2001 19:35:09 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: John Baldwin <jhb@FreeBSD.org> 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: <Pine.LNX.4.10.10101111908440.1606-100000@linux.local> In-Reply-To: <XFMail.010110155358.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 10 Jan 2001, John Baldwin wrote: > On 10-Jan-01 G=E9rard Roudier wrote: > >=20 > > 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 t= he > >> kernel, it is something it should be fully aware of. The locking > >> requirements > >=20 > > Per-cpu variables donnot bite us this more in SMP than in UP, as oppose= d > > 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. ;-) >=20 > 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 'cu= rproc' > "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. Using too much upper-case names or kind of JUMBO-naming in C code does not make the code more readable for the long run. It seems to me that all that useless GROSS naming has been the result of having exacerbated the focus of the day. Uppercase should be reserved mostly for stuff that is supposed to be completely evaluated by compilation phases as: - Constants (#define) - Enumeration tags - Macros accepting constant arguments. As a result, usual stuff as MIN(), MAX(), offsetof() are misnamed in my opinion and should be of the opposite case. Optionnally, complex things like FOR_EACH_ENTRY_OF_SOME_SET(args) may be=20 upper-cased since we must be aware that it has special meaning for ever. Everything else should use lower-case in C, in my opinion. > >> 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 o= pposed > >> to > >> shared variables.) The macros can be made more efficient for the comm= on > >> case > >> (in fact, Jake already has it done) but that is an optimization that c= an be > >> done later. For now let's focus on getting this working right and wor= ry > >> about > >> optimization later. > >=20 > > You seem to have been notified that you started with an immediate > > pessimization. >=20 > Only on the 386 UP case are these macros a pessimization. In fact, if yo= u look > at the old code, all these macros already existed, they just weren't used= =2E=20 > (Instead we #define'd things liek curproc to GLOBAL_LVALUE_NV(curproc) an= d > other weirdness). Also, Jake has another version of these macros that is= more > optimized that doesn't have the extra indirection. Indeed these ones are uglier. :-) > However, there is a growing problem here that I want to state so that eve= ryone > doesn't jump up and down every time we add a clock cycle somewhere: >=20 > Let's get it _right_ first, and optimize later. I didn't disagree with this statement. > Please, with the current state of -current (as many of you should be well > aware, you certainly complain about it enough) getting things working cor= rectly > is _much_ more important than making our machines panic 1us faster than t= hey do > now. Ok? Come on, we knew we were going to be making lots of changes wi= th > this stuff, let's get it right first. The bigger gains in performance ar= e > going to be in the increased parallelism and in reworking algorithms to b= e 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. Neither with this equivalent one. :) Just, per-cpu variables are normally well-known variables, often referenced and that donnot suffer of ordering problems in most places they are referenced. They donnot seems to require to be over-focused for the long run, in my opinion, and should as a result be naturally named, use usual C lowercase naming and accesses should look lvalue-like in most places. G=E9rard. 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.LNX.4.10.10101111908440.1606-100000>