Date: Wed, 10 Jan 2001 11:35:07 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: 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: <XFMail.010110113507.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0101101602240.25131-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10-Jan-01 Bruce Evans wrote: > On Tue, 9 Jan 2001, Jake Burkholder wrote: > >> jake 2001/01/09 20:43:51 PST >> >> Modified files: >> sys/alpha/alpha interrupt.c machdep.c mp_machdep.c prom.c >> trap.c >> sys/dev/usb ohci.c uhci.c usbdi.c >> sys/dev/vinum vinumhdr.h vinummemory.c >> sys/i386/i386 bios.c db_interface.c machdep.c >> mp_machdep.c mpapic.c pmap.c >> sys_machdep.c trap.c vm86.c vm_machdep.c >> sys/i386/include cpu.h >> sys/i386/isa npx.c >> sys/ia64/ia64 interrupt.c mp_machdep.c >> sys/kern init_main.c kern_clock.c kern_exit.c >> kern_ktr.c kern_malloc.c kern_mutex.c >> kern_resource.c kern_shutdown.c >> kern_subr.c kern_switch.c kern_synch.c >> subr_prf.c vfs_bio.c >> sys/sys buf.h >> Log: >> Use PCPU_GET, PCPU_PTR and PCPU_SET to access all per-cpu variables >> other then curproc. > > 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. 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 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. > The corresponding changes for curproc would affect approximately 606 > lines in 163 files. curproc will certainly be the last to be converted. Even BSD/OS has compat 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. > Bruce -- 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.010110113507.jhb>