2011-11-13 23:40:20 UTC
Predictor issues") which improves branch predictor performance
substantially but breaks X86_FS on O3. It turns out the problem is that
an instruction is started which returns from kernel to user level and is
microcoded. The instruction is fetched from the kernel's address space
successfully and starts to execute, along the way dropping down to user
mode. Some microops later, there's some microop control flow which O3
mispredicts. When it squashes the mispredict and tries to restart, it
first tries to refetch the instruction involved. Since it's now at user
level and the instruction is on a kernel level only page, there's a page
fault and things go downhill from there.
I partially implemented a solution to this before where O3 reinstates
the macroop it had been using when it restarts fetch. The problem here
is that the path this kind of squash takes doesn't pass back the right
information, and my attempts to fix that have been unsuccessful. The
code that handles squashing in O3 is too complex, there's too much going
in all directions, it's not always very clear what affect a change will
have in unrelated situations, or which callsites are involved in a
particular type of fault.
To me, it seems like the first step in fixing this problem is to clean
up how squashes are handled in O3 so that they can be made to
consistently handle squashes in non-restartable macroops.
Without having really dug into the specifics, I think we only need two
pieces of information when squashing, a pointer to the guilty
instruction and whether execution should start at or after it. It would
start at it if the instruction needed to be reexecuted due to a memory
dependence violation, for instance, and would start after it for faults,
interrupts, or branch mispredicts. Any other information that's needed
like sequence numbers or actual control flow targets can be retrieved
from the instructions where needed without having to split everything
out and pass them around individually.
Is there any obvious problem with doing things this way? I don't think
I'll personally have a lot of time to dedicate to this at the very least
in the short term, but I wanted to get the conversation going so we know
what to do when somebody has a chance to do it.