Hi,
On Wed, 22 Mar 2023, Alexey Dobriyan wrote:
> Hi, Josh.
>
> I've been profiling how much time livepatching takes and I have a question
> regarding these lines:
>
> void klp_try_complete_transition(void)
> {
> ...
> if (!complete) {
> schedule_delayed_work(&klp_transition_work, round_jiffies_relative(HZ));
> return;
> }
>
> }
>
> The problem here is that if the system is idle, then the previous loop
> checking idle tasks will reliably sets "complete = false" and then
> patching wastes time waiting for next second so that klp_transition_work
> will repeat the same code without reentering itself.
Only if klp_try_switch_task() cannot switch the idle task right away. We
then prod it using wake_up_if_idle() and handle it in the next iteration.
So the question might be why klp_try_switch_task() did not succeed in the
first place.
> I've created trivial patch which changes 2 functions and it takes
> ~1.3 seconds to complete transition:
>
> [ 33.829506] livepatch: 'main': starting patching transition
> [ 35.190721] livepatch: 'main': patching complete
>
> I don't know what's the correct timeout to retry transition work
> but it can be made near-instant:
>
> [ 100.930758] livepatch: 'main': starting patching transition
> [ 100.956190] livepatch: 'main': patching complete
There is really no correct timeout. The application of a live patch is
a lazy slow path. We generally do not care when it is finished unless it
is stuck for some reason or takes really long.
What is your motivation in measuring it?
Regards
Miroslav
