All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikolay Borisov <nik.borisov@suse.com>
To: Ethan Zhao <haifeng.zhao@linux.intel.com>,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: tglx@linutronix.de, dave.hansen@linux.intel.com, x86@kernel.org,
	hpa@zytor.com, xin@zytor.com, andrew.cooper3@citrix.com,
	mingo@redhat.com, bp@alien8.de, etzhao@outlook.com
Subject: Re: [PATCH] x86/fred: Optimize the FRED entry by prioritizing high-probability event dispatching
Date: Thu, 16 Jan 2025 17:08:55 +0200	[thread overview]
Message-ID: <8cf5b264-68be-42b8-b435-79b8d682fd7b@suse.com> (raw)
In-Reply-To: <20250116065145.2747960-1-haifeng.zhao@linux.intel.com>



On 16.01.25 г. 8:51 ч., 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.
> 
<snip>

Can you also include some performance numbers?

> Signed-off-by: Ethan Zhao <haifeng.zhao@linux.intel.com>
> ---
> base commit: 619f0b6fad524f08d493a98d55bac9ab8895e3a6
> ---
>   arch/x86/entry/entry_fred.c | 25 +++++++++++++++++++------
>   1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
> index f004a4dc74c2..591f47771ecf 100644
> --- a/arch/x86/entry/entry_fred.c
> +++ b/arch/x86/entry/entry_fred.c
> @@ -228,9 +228,18 @@ __visible noinstr void fred_entry_from_user(struct pt_regs *regs)
>   	/* Invalidate orig_ax so that syscall_get_nr() works correctly */
>   	regs->orig_ax = -1;
>   
> -	switch (regs->fred_ss.type) {
> -	case EVENT_TYPE_EXTINT:
> +	if (regs->fred_ss.type == EVENT_TYPE_EXTINT)
>   		return fred_extint(regs);
> +	else if (regs->fred_ss.type == EVENT_TYPE_OTHER)
> +		return fred_other(regs);
> +
> +	/*
> +	 * Dispatch EVENT_TYPE_EXTINT and EVENT_TYPE_OTHER(syscall) type events
> +	 * first due to their high probability and let the compiler create binary search
> +	 * dispatching for the remaining events
> +	 */

nit: At least to me it makes sense to have the comment above the 'if' so 
that the flow is linear.

> +
> +	switch (regs->fred_ss.type) {
>   	case EVENT_TYPE_NMI:
>   		if (likely(regs->fred_ss.vector == X86_TRAP_NMI))
>   			return fred_exc_nmi(regs);
> @@ -245,8 +254,6 @@ __visible noinstr void fred_entry_from_user(struct pt_regs *regs)
>   		break;
>   	case EVENT_TYPE_SWEXC:
>   		return fred_swexc(regs, error_code);
> -	case EVENT_TYPE_OTHER:
> -		return fred_other(regs);
>   	default: break;
>   	}
>   
> @@ -260,9 +267,15 @@ __visible noinstr void fred_entry_from_kernel(struct pt_regs *regs)
>   	/* Invalidate orig_ax so that syscall_get_nr() works correctly */
>   	regs->orig_ax = -1;
>   
> -	switch (regs->fred_ss.type) {
> -	case EVENT_TYPE_EXTINT:
> +	if (regs->fred_ss.type == EVENT_TYPE_EXTINT)
>   		return fred_extint(regs);
> +
> +	/*
> +	 * Dispatch EVENT_TYPE_EXTINT type event first due to its high probability
> +	 * and let the compiler do binary search dispatching for the other events
> +	 */
> +
> +	switch (regs->fred_ss.type) {
>   	case EVENT_TYPE_NMI:
>   		if (likely(regs->fred_ss.vector == X86_TRAP_NMI))
>   			return fred_exc_nmi(regs);


  parent reply	other threads:[~2025-01-16 15:08 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-16  6:51 [PATCH] x86/fred: Optimize the FRED entry by prioritizing high-probability event dispatching Ethan Zhao
2025-01-16  6:59 ` kernel test robot
2025-01-16  7:27 ` Xin Li
2025-01-16  9:22   ` Ethan Zhao
2025-01-16 13:03   ` Ethan Zhao
2025-01-16 13:48     ` Xin Li
2025-01-17  0:37       ` Ethan Zhao
2025-01-17  1:21         ` H. Peter Anvin
2025-01-17  3:04           ` Ethan Zhao
2025-01-17  4:19           ` Ethan Zhao
2025-01-17  4:43             ` Xin Li
2025-01-17  5:18               ` Ethan Zhao
2025-01-17  5:54                 ` Xin Li
2025-01-17  6:58                   ` Ethan Zhao
2025-01-17 16:17                   ` H. Peter Anvin
2025-01-17 16:23                     ` H. Peter Anvin
2025-01-18  4:00                       ` Ethan Zhao
2025-01-17 16:24                 ` H. Peter Anvin
2025-01-18  3:29                   ` Ethan Zhao
2025-01-18  3:41                     ` H. Peter Anvin
2025-01-18  4:06                       ` Ethan Zhao
2025-01-18  4:09                         ` H. Peter Anvin
2025-01-18  5:55                           ` Ethan Zhao
2025-01-18  4:14                         ` H. Peter Anvin
2025-01-18  6:02                           ` Ethan Zhao
2025-01-16 15:08 ` Nikolay Borisov [this message]
2025-01-16 18:45   ` Xin Li
2025-01-17  0:40   ` Ethan Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8cf5b264-68be-42b8-b435-79b8d682fd7b@suse.com \
    --to=nik.borisov@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=etzhao@outlook.com \
    --cc=haifeng.zhao@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.