Messages in this thread | | | Subject | Re: [RFC v2 0/6] x86: dynamic indirect branch promotion | From | Adrian Hunter <> | Date | Tue, 8 Jan 2019 12:01:11 +0200 |
| |
On 8/01/19 11:25 AM, Peter Zijlstra wrote: > On Tue, Jan 08, 2019 at 09:47:18AM +0200, Adrian Hunter wrote: >> On 7/01/19 6:32 PM, Peter Zijlstra wrote: >>> On Thu, Jan 03, 2019 at 02:18:15PM -0800, Andi Kleen wrote: >>>> Nadav Amit <namit@vmware.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. >>> >>> I'm thining it would be entirely possible to create and feed text_poke >>> events into the regular (!aux) buffer which can be timestamp correlated >>> to the PT data. >> >> To rebuild kernel text from such events would require a starting point. >> What is the starting point? The problem with kcore is that people can >> deconfig it without realising it is needed to enable the tracing of kernel >> self-modifying code. It would be nice if it was all tied together, so that >> if someone selects the ability to trace kernel self-modifying code, then all >> the bits needed are also selected. Perhaps we should expose another ELF >> image that contains only kernel executable code, and take the opportunity to >> put the symbols in it also. > > Meh; you always need a magic combo of CONFIG symbols to make stuff work. > We don't even have a CONFIG symbol for PT, so if you really care you > should probably start there. > > If you want symbols; what stops us from exposing kallsyms in kcore as > is? > >> Also what about BPF jitted code? Will it always fit in an event? I was >> thinking of trying to add a way to prevent temporarily the unload of modules >> or jitted code, which would be a good-enough solution for now. > > We're working on BPF and kallsym events, those should, esp. when > combined with kcore, allow you to extract the actual instructions.
The problem is that the jitted code gets freed from memory, which is why I suggested the ability to pin it for a while.
| |