[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zhshe66w.fsf@linux.intel.com>
Date: Thu, 03 Jan 2019 14:18:15 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Nadav Amit <namit@...are.com>
Cc: Ingo Molnar <mingo@...hat.com>, Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Edward Cree <ecree@...arflare.com>,
"H . Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
LKML <linux-kernel@...r.kernel.org>,
Nadav Amit <nadav.amit@...il.com>, X86 ML <x86@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Borislav Petkov <bp@...en8.de>,
David Woodhouse <dwmw@...zon.co.uk>, adrian.hunter@...el.com
Subject: Re: [RFC v2 0/6] x86: dynamic indirect branch promotion
Nadav Amit <namit@...are.com> writes:
>
> - Do we use periodic learning or not? Josh suggested to reconfigure the
> branches whenever a new target is found. However, I do not know at
> this time how to do learning efficiently, without making learning much
> more expensive.
FWIW frequent patching will likely completely break perf Processor Trace
decoding, which needs a somewhat stable kernel text image to decode the
traces generated by the CPU. Right now it relies on kcore dumped after
the trace usually being stable because jumplabel changes happen only
infrequently. But if you start patching frequently this assumption will
break.
You would either need a way to turn this off, or provide
updates for every change to the trace, so that the decoder can
keep track.
-Andi
Powered by blists - more mailing lists