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
