From owner-freebsd-smp  Wed Apr 28 16:45: 0 1999
Delivered-To: freebsd-smp@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 48B1E14CEE; Wed, 28 Apr 1999 16:44:54 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id QAA10391;
	Wed, 28 Apr 1999 16:44:52 -0700 (PDT)
	(envelope-from dillon)
Date: Wed, 28 Apr 1999 16:44:52 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199904282344.QAA10391@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
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>
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


: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