Re: [RFC v2 0/6] x86: dynamic indirect branch promotion

[Nadav Amit]

> On Jan 8, 2019, at 9:27 AM, Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote:
> 
> On Tue, Jan 08, 2019 at 11:10:58AM +0100, Peter Zijlstra wrote:
>> On Tue, Jan 08, 2019 at 12:01:11PM +0200, Adrian Hunter wrote:
>>> The problem is that the jitted code gets freed from memory, which is why I
>>> suggested the ability to pin it for a while.
>> 
>> Then what do you tell the guy that keeps PT running for a day and runs
>> out of memory because he likes to JIT a lot?
> 
> It only would need to be saved until the next kcore dump, so they would
> need to do regular kcore dumps, after each of which the JIT code could be freed.
> 
> In a sense it would be like RCU for code.
> 
> You would somehow need to tell the kernel when that happens though
> so it can schedule the frees.
> 
> It doesn't work when the code is modified in place, like the
> patch in the $SUBJECT.

Excuse my ignorance - can you be more concrete what will break where?

I am looking at perf-with-kcore, and intuitively the main thing that is
required is to take text_mutex while kcore is copied, to get a point-in-time
snapshot.

Is it really that important for debugging to get the instructions at the
time of execution? Wouldnât it be easier to annotate the instructions that
might change? After all, it is not as if any instruction can change to any
other instruction.