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

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

[Jun Sun]

Meant to send to the list ....

----- Forwarded message from Jun Sun <jsun@mvista.com> -----

X-Sieve: cmu-sieve 2.0
Date: Tue, 17 Sep 2002 16:02:26 -0700
From: Jun Sun <jsun@mvista.com>
To: Greg Lindahl <lindahl@keyresearch.com>
Cc: jsun@mvista.com
Subject: Re: [RFC] FPU context switch
User-Agent: Mutt/1.2.5i
In-Reply-To: <20020917155854.B1883@wumpus.attbi.com>; from lindahl@keyresearch.com on Tue, Sep 17, 2002 at 03:58:54PM -0700

On Tue, Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote:
> On Wed, Sep 18, 2002 at 12:30:23AM +0200, Kevin D. Kissell wrote:
> 
> > I'm extremely skeptical about this "evidence".
> 
> The only good test is Linux with and without lazy saves. Throwing in a
> new OS complicates matters. It sounds like Jun already has working
> code for (1) and (3), so he can do a good test.
>

I actually have 2) and 3).  1) is easy to do, though.  

Anyone can recommand some test programs to try?

A while back, I tried lmbench which is not very telling.
I think the reason is that most of the tests are not using
FPU at all.

However I might try it again anyway.  It might tell the
difference between 1) and 2)&3) easily.

Jun

----- End forwarded message -----

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

[Kevin D. Kissell]

> ----- Forwarded message from Jun Sun <jsun@mvista.com> -----
Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote:
> > 
> > The only good test is Linux with and without lazy saves. Throwing in a
> > new OS complicates matters. It sounds like Jun already has working
> > code for (1) and (3), so he can do a good test.
> >
> 
> I actually have 2) and 3).  1) is easy to do, though.  
> 
> Anyone can recommand some test programs to try?
> 
> A while back, I tried lmbench which is not very telling.
> I think the reason is that most of the tests are not using
> FPU at all.

"Not very telling?"  Sounds to me as if it confirms the
hypothesis that the benefits of these optimizations are
maginal.  ;-)
 
> However I might try it again anyway.  It might tell the
> difference between 1) and 2)&3) easily.

If I wanted to see the effect at its strongest, I'd whip
up an FP-intensive, low-I/O program along the lines
of the old fashioned Whetstone benchmark that runs
for at least a few seconds, then time a script that 
forks off N of them in parallel with M instances of
a program that does no FP.  You can then play with 
M and N to see where a hack becomes advantageous.  
If all runnable programs are using the FPU, there's 
clearly no benefit from the optimization.

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. 

            Regards,

            Kevin K.

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

[Kevin D. Kissell]

> ----- Forwarded message from Jun Sun <jsun@mvista.com> -----
Sep 17, 2002 at 03:58:54PM -0700, Greg Lindahl wrote:
> > 
> > The only good test is Linux with and without lazy saves. Throwing in a
> > new OS complicates matters. It sounds like Jun already has working
> > code for (1) and (3), so he can do a good test.
> >
> 
> I actually have 2) and 3).  1) is easy to do, though.  
> 
> Anyone can recommand some test programs to try?
> 
> A while back, I tried lmbench which is not very telling.
> I think the reason is that most of the tests are not using
> FPU at all.

"Not very telling?"  Sounds to me as if it confirms the
hypothesis that the benefits of these optimizations are
maginal.  ;-)
 
> However I might try it again anyway.  It might tell the
> difference between 1) and 2)&3) easily.

If I wanted to see the effect at its strongest, I'd whip
up an FP-intensive, low-I/O program along the lines
of the old fashioned Whetstone benchmark that runs
for at least a few seconds, then time a script that 
forks off N of them in parallel with M instances of
a program that does no FP.  You can then play with 
M and N to see where a hack becomes advantageous.  
If all runnable programs are using the FPU, there's 
clearly no benefit from the optimization.

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. 

            Regards,

            Kevin K.

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

[Jun Sun]

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.

Jun

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

[Kevin D. Kissell]

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", 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.

            Regards,

            Kevin K. 

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

[Kevin D. Kissell]

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", 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.

            Regards,

            Kevin K. 

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

[Jun Sun]

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