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

[Ingo Molnar <mingo@kernel.org>]

* Ingo Molnar <mingo@kernel.org> wrote:

>   - implement live kernel upgrades by:
> 
>       - snapshotting all system state transparently

Note that this step can be sped up further in the end, 
because most of this work can be performed asynchronously 
and transparently prior to the live kernel upgrade step 
itself.

So if we split the snapshotting+parking preparatory step 
into two parts:

        - do opportunistic snapshotting of 
          sleeping/inactive user tasks while allowing 
          snapshotted tasks to continue to run

        - once that is completed, do snapshotting+parking 
          of all user tasks, even running ones

The first step is largely asynchronous, can be done with 
lower priority and does not park/stop any tasks on the 
system.

Only the second step counts as 'system stoppage time': and 
only those tasks have to be snapshotted again which 
executed any code since the first snapshotting run was 
performed.

Note that even this stoppage time can be reduced further: 
if a system is running critical services/users that need as 
little interruption as possible, they could be 
prioritized/ordered to be snapshotted/parked closest to the 
live kernel upgrade step.

>       - fast-rebooting into the new kernel image without 
>         shutting down and rebooting user-space, i.e. _much_ 
>         faster than a regular reboot.
> 
>       - restoring system state transparently within the new 
>         kernel image and resuming system workloads where 
>         they were left.
> 
> Even complex external state like TCP socket state and 
> graphics state can be preserved over an upgrade. As far 
> as the user is concerned, nothing happened but a brief 
> pause - and he's now running a v3.21 kernel, not v3.20.

So all this would allow 'live, rolling kernel upgrades' in 
the end.

Thanks,

	Ingo