Date: Wed, 7 Aug 2002 00:18:32 -0700 From: Luigi Rizzo <rizzo@icir.org> To: Terry Lambert <tlambert2@mindspring.com> Cc: Julian Elischer <julian@elischer.org>, Peter Wemm <peter@wemm.org>, smp@freebsd.org Subject: Re: how to create per-cpu variables in SMP kernels ? Message-ID: <20020807001832.C37532@iguana.icir.org> In-Reply-To: <3D504B0A.9FDB3A47@mindspring.com>; from tlambert2@mindspring.com on Tue, Aug 06, 2002 at 03:17:46PM -0700 References: <Pine.BSF.4.21.0208061005150.65715-100000@InterJet.elischer.org> <3D504B0A.9FDB3A47@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Tue, Aug 06, 2002 at 03:17:46PM -0700, Terry Lambert wrote:
...
> Julian, I'm not sure that Luigi is dealing with SMP on -current
> rather than SMP on -stable.
...
> The main probem here is that Luigi is talking about per-CPU per
> process stuff.
>
> If you guys keep going down this road, you are not going to be
> thinking about CPU cycles as if they were anonymous resources.
>
> It would be an incredible mistake, IMO, for Luigi to maintain
> per-CPU state off the %FS. His problem is that he wants to have
Terry keeps stating what *I* am supposed to have in mind, but
I am not sure we agree on that :)
The motivation for my question was mostly to understood how to understood
how the per-CPU data is stored and how expensive is to access it.
As for why i need it, there are at least two places.
One is the scheduler -- when a new thread/process becomes ready
for execution, i might need to preempt the "least important"
among those currently in execution, and these things are not
in any queue, but stored in the cur{thread|proc} variables of
individual CPUS. I do not need to add additional per-CPU variabies
here, nor to modify this information, just to read it.
The second place might be the network stack, because there we collect
all sort of statistics on packets. If we ever decide to move
this code under a finer granularity locking scheme, rather than have a large
number of atomic_add_*() to replace all the counter increments,
and depending on how expensive is to access the per-cpu data, it
might make sense to split these statistics on a per-CPU basis, and
let the programs doing the collection take a snapshot and add them up.
Now i see that in all other architectures the per-cpu data is
accessed through a dedicated register (see the snapshot below for
the alpha, but it is similar for sparc and ia64).
alpha/include/pcpu.h
register struct pcpu *pcpup __asm__("$8");
#define PCPU_GET(member) (pcpup->pc_ ## member)
#define PCPU_PTR(member) (&pcpup->pc_ ## member)
#define PCPU_SET(member,value) (pcpup->pc_ ## member = (value))
Unfortunately the i386 case looks less efficient, or at least more
convoluted to handle, because we need to use %fs due to lack of
general registers (maybe one could write something like
register struct pcpu *pcpup __asm__("%%fs:0");
if gcc were able to parse this syntax
cheers
luigi
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?20020807001832.C37532>