On 1/18/2025 12:23 AM, H. Peter Anvin wrote:
On 1/17/25 08:17, H. Peter Anvin wrote:
- switch (regs->fred_ss.type) { + switch_likely (etype, (EVENT_TYPE_EXTINT == etype || EVENT_TYPE_OTHER == etype)) {
This is not what I suggested, the (l) argument should be only one constant; __builtin_expect() doesn't allow 2 different constants.
The (l) argument is not a boolean expression! It is the *expected value* of (v).
Also, EVENT_TYPE_EXTINT == etype is not Linux style.
More fundamentally, though, I have to question this unless based on profiling, because it isn't at all clear that EXTINT is more important than FAULT (page faults, to be specific.)
Perhaps the conclusion about which is more important/higher probability among EXTINT,SYSCALL,PF only applies to specific kind of workload system, no one-size-fit-all conclusion there to dig.
But for a normal system, it is certainty that events like EXTINT,SYSCALL,PF would happen in higher probability than others. saving some cycles for their paths isn't hard to understand. just like taking shortcut at event type dispatching level, no other changes.
To optimize syscalls, you want to do a one-shot comparison of the entire syscall64 signature (event type, 64-bit flag, and vector) as a mask and compare. For
To whole event dispatching path for syscalls, yep.
that you want to make sure the compiler loads the high 32 bits into a register so that your mask and compare values can be immediates. In other words, you don't actually want it to be part of the switch at all, and you want *other* EVENT_TYPE_OTHER to fall back to the switch with regular (low) priority.
switch() seems not too bad, at least compared to jump table.
Thanks, Ethan
-hpa