Date: Wed, 10 Jan 2001 22:33:41 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: John Baldwin <jhb@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Jake Burkholder <jake@FreeBSD.org> Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c machdep.c mp_mac Message-ID: <Pine.LNX.4.10.10101102158040.1951-100000@linux.local> In-Reply-To: <XFMail.010110113507.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 Bruce Evans wrote: > > On Tue, 9 Jan 2001, Jake Burkholder wrote: > >=20 > >> jake 2001/01/09 20:43:51 PST > >>=20 > >> Modified files: > >> sys/alpha/alpha interrupt.c machdep.c mp_machdep.c prom.c=20 > >> trap.c=20 > >> sys/dev/usb ohci.c uhci.c usbdi.c=20 > >> sys/dev/vinum vinumhdr.h vinummemory.c=20 > >> sys/i386/i386 bios.c db_interface.c machdep.c=20 > >> mp_machdep.c mpapic.c pmap.c=20 > >> sys_machdep.c trap.c vm86.c vm_machdep.c=20 > >> sys/i386/include cpu.h=20 > >> sys/i386/isa npx.c=20 > >> sys/ia64/ia64 interrupt.c mp_machdep.c=20 > >> sys/kern init_main.c kern_clock.c kern_exit.c=20 > >> kern_ktr.c kern_malloc.c kern_mutex.c=20 > >> kern_resource.c kern_shutdown.c=20 > >> kern_subr.c kern_switch.c kern_synch.c=20 > >> subr_prf.c vfs_bio.c=20 > >> sys/sys buf.h=20 > >> Log: > >> Use PCPU_GET, PCPU_PTR and PCPU_SET to access all per-cpu variables > >> other then curproc. > >=20 > > I wish I had objected earlier to your previous changes to prepare for > > this mistake. Machine-independent code shouldn't know that some > > variables are per-cpu. We had perfectly good access macros named > > curproc, etc. (except they weren't ifdefed right for modules). There > > is no need for function-like macros, since rvalue-like variables can > > always be implemented using macros (or [inline] functions) that return > > the value of the variable, and lvalue-like variables can always be > > implemented as `*(macro_that_returns_address_of_variable)'. This is > > what the old macros did. The `SET' macros can be more efficient in > > some cases, since they may be able to access the variable directly, > > but we currently don't do this. In fact, even the i386 `GET' macros > > have regressed from direct accesses in the %fs segment to indirect > > accesses via a pointer loaded from the %fs segment. >=20 > There is nothign wrong with MI code knowing that it is running on a SMP-a= ware > 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 require= ments 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. ;-) > are different for per-cpu variables than for global ones for example. (M= ost > per-cpu variables don't need locking since they aren't contended, as oppo= sed 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. > > The corresponding changes for curproc would affect approximately 606 > > lines in 163 files. >=20 > curproc will certainly be the last to be converted. Even BSD/OS has comp= at > macros for this still. However, making the kernel SMP aware is going to = cause > changes in interfaces. We can't rework the kernel and expect nothing to = change. SMP is a new awareness for the kernel that also must be aware of thousands of other issues. Do we want to upper-case everything the kernel must be aware of? 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.10101102158040.1951-100000>