Date: Wed, 28 Apr 1999 16:44:52 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alan Cox <alc@cs.rice.edu> 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: <199904282344.QAA10391@apollo.backplane.com> 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> <19990428180020.P1121@nonpc.cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904282344.QAA10391>