From owner-freebsd-current Wed Apr 28 16: 0:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 74C4D14EC4; Wed, 28 Apr 1999 16:00:22 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: from nonpc.cs.rice.edu (nonpc.cs.rice.edu [128.42.1.219]) by cs.rice.edu (8.9.0/8.9.0) with ESMTP id SAA29228; Wed, 28 Apr 1999 18:00:21 -0500 (CDT) Received: (from alc@localhost) by nonpc.cs.rice.edu (8.9.2/8.7.3) id SAA15816; Wed, 28 Apr 1999 18:00:21 -0500 (CDT) Date: Wed, 28 Apr 1999 18:00:20 -0500 From: Alan Cox To: Matthew Dillon Cc: Chuck Robey , Poul-Henning Kamp , Luoqi Chen , current@freebsd.org, smp@freebsd.org Subject: Re: HEADS UP! to commit SMP vmspace sharing patches Message-ID: <19990428180020.P1121@nonpc.cs.rice.edu> References: <199904281819.LAA07937@apollo.backplane.com> <19990428151454.O1121@nonpc.cs.rice.edu> <199904282148.OAA09354@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904282148.OAA09354@apollo.backplane.com>; from Matthew Dillon on Wed, Apr 28, 1999 at 02:48:56PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 28, 1999 at 02:48:56PM -0700, Matthew Dillon wrote: > > ... > > There might be less confusion with %fs if we simply use it as a > 'cpu number' index and then make all the cpu-dependant variables > standard arrays. i.e. instead if 'struct proc *curproc' we would > have 'struct proc *curproc[NCPU];'. The assembly macro would > simply retrieive the current cpu number from %fs, so: > > curproc[MYCPU] = ... > > This would be much less confusing then trying to encapsulate the concept > of 'curproc', and we could do away with cpu-specific VM areas entirely. > > Sure, it would eat a few more cycles, but I don't think it would effect > performance. > I don't think the current approach with %fs is that confusing. :-) You can view it as an optimization of struct "per processor data" { struct proc *curproc; ... } ppd[NCPUS]; some_func() { ... ppd[MYCPU]->curproc In some sense, the "ppd[MYCPU]" is precomputed in %fs. Also, I would discourage a "per-variable" approach like struct proc *curproc[NCPU]; This will lead to unnecessary cache coherence traffic (due to false sharing). For example, when processor 0 updates curproc[0] it will cause the invalidation of the cache line containing curproc on processor 1, and vice versa when processor 1 updates curproc[1]. Instead, it's better to aggregate each processor's per-processor data like our current code does. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message