[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d9bcbb64-6961-c52f-bb8e-bef3c424e224@siemens.com>
Date: Tue, 18 Jun 2019 16:56:03 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Dave Hansen <dave.hansen@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Optimize load_mm_cr4 to load_mm_cr4_irqsoff
On 18.06.19 16:41, Dave Hansen wrote:
> On 6/18/19 12:32 AM, Jan Kiszka wrote:
>> Thus, we can avoid disabling interrupts again in cr4_set/clear_bits.
>
> Seems reasonable.
>
> Your *_irqsoff() variants need lockdep_assert_irqs_disabled(), at least,
> though.
It inherits this check via __cr4_set, so I didn't add that to the outer path.
>
> Can you talk a bit about the motivation here, though? Did you encounter
> some performance issue that led you to make this patch, or was it simply
> an improvement you realized you could make from code inspection?
>
I ran into a downstream issue adjusting patches to this code. In a nutshell,
Xenomai has something like an NMI context over most Linux code that shares some
codepaths with the kernel, though. One of them is switch_mm_irqs_off, and there
our checking logic warned. The rest was code inspection.
For upstream, this is a micro-optimization. But given that something like
switch_mm is in the path, I thought it's worth to propose.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
Powered by blists - more mailing lists