Re: [jsun@mvista.com: Re: [RFC] FPU context switch]

[Jun Sun <jsun@mvista.com>]

On Wed, Sep 18, 2002 at 10:45:08AM +0200, Kevin D. Kissell wrote:
> From: "Jun Sun" <jsun@mvista.com>
> > 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.

Jun