Date: Thu, 15 Nov 2001 13:29:45 +1030
From: Greg Lehey <grog@FreeBSD.org>
To: Bruce Evans <bde@zeta.org.au>, Matthew Dillon <dillon@apollo.backplane.com>
Cc: Peter Wemm <peter@wemm.org>, Robert Watson <rwatson@FreeBSD.ORG>, freebsd-arch@FreeBSD.ORG
Subject: Re: cur{thread/proc}, or not.
Message-ID: <20011115132945.C33267@monorchid.lemis.com>
In-Reply-To: <200111121009.fACA9SI75024@apollo.backplane.com> <20011112165530.B34657-100000@delplex.bde.org>
References: <20011112165530.B34657-100000@delplex.bde.org> <200111121009.fACA9SI75024@apollo.backplane.com> <20011111191735.00D053807@overcee.netplex.com.au> <20011112165530.B34657-100000@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 12 November 2001 at 17:32:12 +1100, Bruce Evans wrote: > On Sun, 11 Nov 2001, Peter Wemm wrote: > >> Robert Watson wrote: >> >>> It seems to me that unless a very strong argument exists against using >>> curproc/curthread (and I don't preclude one existing), using them would >>> actually be an improvement, as it would assert that this class of > >> My gripe is that on i386, it creates a LOT of work for the compiler. > > That's just an implementation detail for one arch. I did strongly object > to the implementation, but... I must say that I don't have much sympathy for the compiler. If it also creates a lot of work for the processors, that's a different matter. >> Count me in the 'curproc considered harmful' camp. (or curthread). > > Count me ouside of it. Agreed (for once). On Monday, 12 November 2001 at 2:09:28 -0800, Matthew Dillon wrote: >> Passing the pointer down through 20 subroutines (some of which don't >> even use it except to pass it along) may add up to much. >> >> Bruce > > I agree that it is kind of silly to pass a global down through N levels > of procedures. Just on principle. On the otherhand I don't expect > the performance to be better or worse, or even for there to be any > real difference in code size. Fewer instructions per routine in > more routines, with more memory writes (pass as argument on stack), > verses more instructions in fewer routines, with only memory reads > (access as global). Without there being a clear winner there isn't > much of a reason to change the existing code. OK, I've just got back from a conference to find several thousand messages, many of them requiring to be read, so I haven't had much time to look at this, but wouldn't it make more sense to pass the proc or thread pointer (or whatever substructure is really needed) in a structure which is being handed from function to function anyway? struct buf would appear to be the correct one in this case. I would also expect this to make it easier for exceptions like NFS code. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011115132945.C33267>