: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
Quite true. But, in that case, the equivalent of
struct perprocess {
struct process *curproc;
...
} perproc[NCPU];
While it is true that you then have to draw out the access:
perproc[MYCPU].curproc
Or perhaps ( even better ):
MYCPU->curproc
It would make the code much more readable then trying to 'hide' the
fact that curproc ( and other variables ) are actually segmented. We
have to keep in mind the fact that SMP is only just now gaining momentum,
and I think a considerable amount of additional data and structure is
going to be added to the per-cpu structures in the next few years as
we begin to parallelize kernel operations.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
