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: <05b13e99-c7e5-4db7-90bd-a89a91f4e327@zytor.com>
Date: Thu, 16 Jan 2025 05:48:47 -0800
From: Xin Li <xin@...or.com>
To: Ethan Zhao <etzhao@...look.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,
        hpa@...or.com, 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/16/2025 5:03 AM, Ethan Zhao wrote:
> On 1/16/2025 3:27 PM, Xin Li wrote:
>> On 1/15/2025 10:51 PM, Ethan Zhao wrote:
>>> External interrupts (EVENT_TYPE_EXTINT) and system calls 
>>> (EVENT_TYPE_OTHER)
>>> occur more frequently than other events in a typical system. 
>>> Prioritizing
>>> these events saves CPU cycles and optimizes the efficiency of 
>>> performance-
>>> critical paths.
>>
>> We deliberately hold off sending performance improvement patches at this
>> point, but first of all please read:
>> https://lore.kernel.org/lkml/87fs766o3t.ffs@tglx/
> 
> Do you mean Thomas'point "Premature optimization is the enemy of 
> correctness.
> don't do it" ? Yep, I agree with it.

Yes.

> 
> Compared to the asm code generated by the compiler with fewer than 20 cmp
> instructions, placing a event handler jump table indexed by event- 
> typethere is a negative optimization. That is not deliberately 'hold 
> off', correctness goes first, definitely right.

hpa suggested to introduce "switch_likely" for this kind of optimization
on a switch statement, which is also easier to read.  I measured it with
a user space focus test, it does improve performance a lot.  But 
obviously there are still a lot of work to do.

Thanks!
     Xin