[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <289e420d-a465-41c9-82ee-68ffbbfba0de@linux.intel.com>
Date: Fri, 17 Jan 2025 11:04:30 +0800
From: Ethan Zhao <haifeng.zhao@...ux.intel.com>
To: "H. Peter Anvin" <hpa@...or.com>, Ethan Zhao <etzhao@...look.com>,
Xin Li <xin@...or.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
在 2025/1/17 9:21, H. Peter Anvin 写道:
> On 1/16/25 16:37, Ethan Zhao wrote:
>>>
>>> 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.
>>
>
> It's not that complicated, believe it or not.
>
> /*
> * switch(v) biased for speed in the case v == l
> *
> * Note: gcc is quite sensitive to the exact form of this
> * expression.
> */
> #define switch_likely(v,l) \
> switch((__typeof__(v))__builtin_expect((v),(l)))
>
I know we could play such trick for one branch, never think of there are
2-3 branches
are expected among 7 branches. :) , --- external interrupts, syscall,
page fault.
Thanks,
Ethan
> -hpa
>
--
"firm, enduring, strong, and long-lived"
Powered by blists - more mailing lists