linux-kernel - Re: [PATCH] x86/fred: Optimize the FRED entry by prioritizing high-probability event dispatching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <TYZPR03MB8801A04C30D95381FD9205BED1E52@TYZPR03MB8801.apcprd03.prod.outlook.com>
Date: Sat, 18 Jan 2025 12:00:46 +0800
From: Ethan Zhao <etzhao@...look.com>
To: "H. Peter Anvin" <hpa@...or.com>, Xin Li <xin@...or.com>,
 Ethan Zhao <haifeng.zhao@...ux.intel.com>, linux-kernel@...r.kernel.org,
 stable@...r.kernel.org
Cc: tglx@...utronix.de, dave.hansen@...ux.intel.com, x86@...nel.org,
 andrew.cooper3@...rix.com, mingo@...hat.com, bp@...en8.de
Subject: Re: [PATCH] x86/fred: Optimize the FRED entry by prioritizing
 high-probability event dispatching

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
>