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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <TYZPR03MB88013A5D71079FF9E6776E49D11B2@TYZPR03MB8801.apcprd03.prod.outlook.com>
Date: Fri, 17 Jan 2025 08:37:10 +0800
From: Ethan Zhao <etzhao@...look.com>
To: 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,
 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 9:48 PM, Xin Li wrote:
> 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.

Find a way to instruct compiler to pick the right hot branch meanwhile make folks
reading happy... yup, a lot of work.

Thanks,
Ethan

>
> Thanks!
>     Xin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ