[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Mar 2023 23:17:05 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: "Eranian, Stephane" <eranian@...gle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "peterz@...radead.org" <peterz@...radead.org>,
"Chatre, Reinette" <reinette.chatre@...el.com>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
"peternewman@...gle.com" <peternewman@...gle.com>,
"bp@...e.de" <bp@...e.de>,
"james.morse@....com" <james.morse@....com>,
"babu.moger@....com" <babu.moger@....com>,
"ananth.narayan@....com" <ananth.narayan@....com>,
"vschneid@...hat.com" <vschneid@...hat.com>
Subject: RE: [PATCH] x86/resctrl: avoid compiler optimization in
__resctrl_sched_in
> However in the __switch_to() routine, the current point is changed. If the
> compiler optimizes away the reload, then the resctrl_sched_in will look
> at the previous task instead of the new current task. This explains why we
> were not seeing the limit enforced on the benchmark.
Are there any other uses of "current" during context switch that might
be affected by this?
-Tony
Powered by blists - more mailing lists