* Ingo Molnar <mi...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
