Date: Wed, 28 Apr 1999 18:00:20 -0500 From: Alan Cox <alc@cs.rice.edu> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Chuck Robey <chuckr@picnic.mat.net>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Luoqi Chen <luoqi@watermarkgroup.com>, current@freebsd.org, smp@freebsd.org Subject: Re: HEADS UP! to commit SMP vmspace sharing patches Message-ID: <19990428180020.P1121@nonpc.cs.rice.edu> In-Reply-To: <199904282148.OAA09354@apollo.backplane.com>; from Matthew Dillon on Wed, Apr 28, 1999 at 02:48:56PM -0700 References: <Pine.BSF.4.10.9904281400540.378-100000@picnic.mat.net> <199904281819.LAA07937@apollo.backplane.com> <19990428151454.O1121@nonpc.cs.rice.edu> <199904282148.OAA09354@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990428180020.P1121>