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

[Kumar Gala]

On Mar 13, 2009, at 3:23 PM, Ryan Arnold wrote:

> Hi all,
>
> Those of us working on the POWER toolchain can envision a certain  
> class
> of customers who may benefit from intelligently disabling certain
> register class enable bits on context switches, i.e. not disabling by
> default.
>
> Currently, per process, if the MSR enable bits for FPs, VRs or VSRs  
> are
> set to disabled, an interrupt will be generated as soon as an FP, VMX,
> or VSX instruction is encountered.  At this point the kernel enables  
> the
> relevant bits in the MSR and returns.
>
> Currently, the kernel will disable all of the bits on a context  
> switch.
>
> If a customer _knows_ a process will be using a register class
> extensively, e.g. VRs, they're paying the interrupt->enable-VMX price
> with every context switch.  It'd be nice if we could intelligently  
> leave
> the bits enabled.
>
> Solutions:
> - A boot flag which always enables VSRs, VRs, FPRs, etc.  These are
> cumulative, i.e. VSRs implies VRs and FPRS; VRs implies FPRs.
>
> - A heuristic which permanently enables said register classes for a
> process if they've been enabled during the previous X interrupts.
>
> - The same heuristic could disable the register class bits after a
> certain criteria is met.
>
> We have some ideas on how to benchmark this to verify the expense of  
> the
> interrupt->enable.  As it presently works this stands in the way of
> using VMX or VSX for optimized string routines in GLIBC.

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.

- k