All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: He Ying <heying24@huawei.com>
Cc: catalin.marinas@arm.com, will@kernel.org, marcan@marcan.st,
	maz@kernel.org, joey.gouly@arm.com, pcc@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Make CONFIG_ARM64_PSEUDO_NMI macro wrap all the pseudo-NMI code
Date: Tue, 11 Jan 2022 11:05:06 +0000	[thread overview]
Message-ID: <Yd1kYu8CMlGYeb20@FVFF77S0Q05N> (raw)
In-Reply-To: <168f7e83-e815-f10e-3a43-8529aab77f1e@huawei.com>

On Tue, Jan 11, 2022 at 04:52:32PM +0800, He Ying wrote:
> 在 2022/1/10 19:26, Mark Rutland 写道:
> > On Mon, Jan 10, 2022 at 11:00:43AM +0800, He Ying wrote:
> > > 在 2022/1/7 21:19, Mark Rutland 写道:
> > > > On Fri, Jan 07, 2022 at 03:55:36AM -0500, He Ying wrote:
 
> > Due to the large numbers, I suspect this must be due to a specific fast-path,
> > and it's possible that this is due to secondary factors (e.g. alignment of
> > code) rather than the pseudo-NMK code itself.
> > 
> > We need to narrow down *where* time is being spent. Since it appears that this
> > is related to the local IRQ state management, it isn't likely that we can
> > determine that reliably with the PMU. Given that, I think the first step is to
> > reproduce the result elsewhere, for which we will need some plublicly available
> > test-case.
> 
> As said before, I asked our collegues how they did the ARP test. In one word,
> a very small performance regression may bring the big change to the test
> result.
> 
> I feel very sorry for missing this important information. So, this patch may
> improve the performance a little and then lead to the big change to the
> test result.

No problem; thanks for confirming.

[...]

> OK, I see. What do you think if I send a v2 patch that only adds ifdeffery
> to
> 
> arch/arm64/kernel/entry.S and leave the rework to ALERNATIVE behind?

I think that would be reasonable given we do that for other bits in entry.S;
I'd be happy with such a patch.

Thanks,
Mark.

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: He Ying <heying24@huawei.com>
Cc: catalin.marinas@arm.com, will@kernel.org, marcan@marcan.st,
	maz@kernel.org, joey.gouly@arm.com, pcc@google.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: Make CONFIG_ARM64_PSEUDO_NMI macro wrap all the pseudo-NMI code
Date: Tue, 11 Jan 2022 11:05:06 +0000	[thread overview]
Message-ID: <Yd1kYu8CMlGYeb20@FVFF77S0Q05N> (raw)
In-Reply-To: <168f7e83-e815-f10e-3a43-8529aab77f1e@huawei.com>

On Tue, Jan 11, 2022 at 04:52:32PM +0800, He Ying wrote:
> 在 2022/1/10 19:26, Mark Rutland 写道:
> > On Mon, Jan 10, 2022 at 11:00:43AM +0800, He Ying wrote:
> > > 在 2022/1/7 21:19, Mark Rutland 写道:
> > > > On Fri, Jan 07, 2022 at 03:55:36AM -0500, He Ying wrote:
 
> > Due to the large numbers, I suspect this must be due to a specific fast-path,
> > and it's possible that this is due to secondary factors (e.g. alignment of
> > code) rather than the pseudo-NMK code itself.
> > 
> > We need to narrow down *where* time is being spent. Since it appears that this
> > is related to the local IRQ state management, it isn't likely that we can
> > determine that reliably with the PMU. Given that, I think the first step is to
> > reproduce the result elsewhere, for which we will need some plublicly available
> > test-case.
> 
> As said before, I asked our collegues how they did the ARP test. In one word,
> a very small performance regression may bring the big change to the test
> result.
> 
> I feel very sorry for missing this important information. So, this patch may
> improve the performance a little and then lead to the big change to the
> test result.

No problem; thanks for confirming.

[...]

> OK, I see. What do you think if I send a v2 patch that only adds ifdeffery
> to
> 
> arch/arm64/kernel/entry.S and leave the rework to ALERNATIVE behind?

I think that would be reasonable given we do that for other bits in entry.S;
I'd be happy with such a patch.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-01-11 11:05 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07  8:55 [PATCH] arm64: Make CONFIG_ARM64_PSEUDO_NMI macro wrap all the pseudo-NMI code He Ying
2022-01-07  8:55 ` He Ying
2022-01-07 13:19 ` Mark Rutland
2022-01-07 13:19   ` Mark Rutland
2022-01-10  3:00   ` He Ying
2022-01-10  3:00     ` He Ying
2022-01-10 11:26     ` Mark Rutland
2022-01-10 11:26       ` Mark Rutland
2022-01-11  8:52       ` He Ying
2022-01-11  8:52         ` He Ying
2022-01-11 11:05         ` Mark Rutland [this message]
2022-01-11 11:05           ` Mark Rutland
2022-01-08 12:51 ` Marc Zyngier
2022-01-08 12:51   ` Marc Zyngier
2022-01-10  3:20   ` He Ying
2022-01-10  3:20     ` He Ying
2022-01-12  3:24 ` [PATCH] arm64: entry: Save some nops when CONFIG_ARM64_PSEUDO_NMI is not set He Ying
2022-01-12  3:24   ` He Ying
2022-01-19  6:40   ` He Ying
2022-01-19  6:40     ` He Ying
2022-01-19  9:35     ` Mark Rutland
2022-01-19  9:35       ` Mark Rutland
2022-01-19  9:47       ` He Ying
2022-01-19  9:47         ` He Ying
2022-02-15 23:18   ` Will Deacon
2022-02-15 23:18     ` Will Deacon

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=Yd1kYu8CMlGYeb20@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=heying24@huawei.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=maz@kernel.org \
    --cc=pcc@google.com \
    --cc=will@kernel.org \
    /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.