Subject: Re: [RFC] Moving toward smarter disabling of FPRs, VRs, and VSRs in the MSR

From: Ryan Arnold <[email-masked]>
Date: Fri, 13 Mar 2009 21:31:46 -0500

On Sat, 2009-03-14 at 09:45 +1100, Benjamin Herrenschmidt wrote:
> > If these applications are aware they are heavy users (of FP, VMX, VSX)  
> > can we not use a sysctl()?  Doing so wouldn't be that difficult.
> > 
> > I think trying to do something based on a runtime heuristic sounds a  
> > bit iffy.
> 
> Another option might be simply to say that if an app has used FP, VMX or
> VSX -once-, then it's likely to do it again and just keep re-enabling
> it :-)
> 
> I'm serious here, do we know that many cases where these things are used
> seldomly once in a while ?
> 
> An if we do, maybe then a simple counter in the task struct... if the
> app re-enables it more than a few consecutive switches, then make it
> stick. I have the feeling that would work out reasonably well.

Both of these thoughts came to mind.  I don't have a particular
preference.  It's very likely that a process which results in the
enabling of FP,VMX, or VSX may continue to use the facility for the
duration of it's lifetime.  Threads would be even more likely to exhibit
this behavior.

The case where this might not be true is if we use VMX or VSX for string
routine optimization in GLIBC.  This will require metrics to prove it's
utility of course.  Perhaps what I can do in the string routines is
check if the bits are already set and use the facility if it is already
enabled and the usage scenario warrants it, i.e. if the size and
alignment of the data are in a sweet spot as indicated by profiling
data.

Regards,
Ryan