[<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