Skip site navigation (1)Skip section navigation (2)
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>