Re: live kernel upgrades (was: live kernel patching design)

[Petr Mladek <pmladek@suse.cz>]

On Tue 2015-02-24 11:23:29, Ingo Molnar wrote:
> What gradual improvements in live upgrade latency am I 
> talking about?
> 
>  - For example the majority of pure user-space process 
>    pages in RAM could be saved from the old kernel over 
>    into the new kernel - i.e. they'd stay in place in RAM, 
>    but they'd be re-hashed for the new data structures. 

I wonder how many structures we would need to rehash when we update
the whole kernel. I think that it is not only about memory but also
about any other subsystem: networking, scheduler, ...


>  - Hardware devices could be marked as 'already in well
>    defined state', skipping the more expensive steps of 
>    driver initialization.

This is another point that might get easily wrong. We know that
the quality of many drivers is not good. Yes, we want to make it
better. But we also know that system suspend does not work well
on many systems for years even with the huge effort.


>  - Possibly full user-space page tables could be preserved 
>    over an upgrade: this way user-space execution would be 
>    unaffected even in the micro level: cache layout, TLB
>    patterns, etc.
> 
> There's lots of gradual speedups possible with such a model 
> IMO.
> 
> With live kernel patching we run into a brick wall of 
> complexity straight away: we have to analyze the nature of 
> the kernel modification, in the context of live patching, 
> and that only works for the simplest of kernel 
> modifications.
> 
> With live kernel upgrades no such brick wall exists, just 
> about any transition between kernel versions is possible.

I see here a big difference in the complexity. If verifying patches
is considered as complex then I think that it is much much more
complicated to verify that the whole kernel upgrade is safe and
that all states will be properly preserved and reused.

Otherwise, I think that live patching won't be for any Joe User.
The people producing patches will need to investigate the
changes anyway. They will not blindly take a patch on internet
and convert it to a life patch. I think that this is true for
many other kernel features.


> Granted, with live kernel upgrades it's much more complex 
> to get the 'simple' case into an even rudimentarily working 
> fashion (full userspace state has to be enumerated, saved 
> and restored), but once we are there, it's a whole new 
> category of goodness and it probably covers 90%+ of the 
> live kernel patching usecases on day 1 already ...

I like the idea and I see the benefit for other tasks: system suspend,
migration of systems to another hardware, ... But I also think that it
is another level of functionality.

IMHO, live patching is somewhere on the way for the full kernel
update and it will help as well. For example, we will need to somehow
solve transition of kthreads and thus fix their parking.

I think that live patching deserves its separate solution. I consider
it much less risky but still valuable. I am sure that it will have
its users. Also it will not block improving the things for the full
update in the future.


Best Regards,
Petr