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 majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
