On Wed, Sep 18, 2002 at 10:45:08AM +0200, Kevin D. Kissell wrote:
> From: "Jun Sun" <firstname.lastname@example.org>
> > On Wed, Sep 18, 2002 at 02:10:17AM +0200, Kevin D. Kissell wrote:
> > > Are you able to test this stuff on a proper SMP
> > > system, by the way? The efficiency of the code
> > > that manipulates interprocessor control variables
> > > can reasonably be expected to drop off a bit
> > > in a system with MP cache invalidations blasting
> > > left and right.
> > Yes. I understand this effect. Solution 1), 2)
> > and 3) don't really suffer from this problem because
> > variables tested & manipulated are local - unless the
> > process migrates which is a different problem.
> It's not a "different problem",
Process migration causeing inter-processor memory access traffic
(which should be one-time) belongs to scheduling issue. It is
a different problem.
> it's the heart of the
> problem. If we weren't worried about SMP
> behavior, we wouldn't be revisiting this stuff.
> While (1) can obviously be done without any
> global knowledge, as could something (2)-like
> based on CPU-local state such as Status.CU1,
> (2), (3) and (4), as you describe them, all depend
> to some degree on shared multiprocessor variables
> to determine whether to save or restore FP state.
1), 2), 3) do not depend on global variables with shared
access from multiple cpus. Please read again.
Please note variables of "current" process do not cause
inter-processor traffic and thus not belong to this category.