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
next prev parent 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: linkBe 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.