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

[Ryan Arnold <rsa@us.ibm.com>]

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.

Regards,

Ryan S. Arnold
IBM Linux Technology Center
Linux Toolchain Development