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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
