lkml.org 
[lkml]   [2015]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: live kernel upgrades (was: live kernel patching design)
On Tue, Feb 24, 2015 at 11:53:28AM +0100, Ingo Molnar wrote:
>
> * Jiri Kosina <jkosina@suse.cz> wrote:
>
> > [...] We could optimize the kernel the craziest way we
> > can, but hardware takes its time to reinitialize. And in
> > most cases, you'd really need to reinitalize it; [...]
>
> If we want to reinitialize a device, most of the longer
> initialization latencies during bootup these days involve
> things like: 'poke hardware, see if there's any response'.
> Those are mostly going away quickly with modern,
> well-enumerated hardware interfaces.
>
> Just try a modprobe of a random hardware driver - most
> initialization sequences are very fast. (That's how people
> are able to do cold bootups in less than 1 second.)

Have you ever tried to boot a system with a large (> 100) number of
drives connected over FC? That takes time to discover and you have to do
the discovery as the configuration could have changed while you were not
looking.

Or a machine with terabytes of memory? Just initializing the memory
takes minutes.

Or a desktop with USB? And you have to reinitialize the USB bus and the
state of all the USB devices, because an application might be accessing
files on an USB drive.

> In theory this could also be optimized: we could avoid the
> reinitialization step through an upgrade via relatively
> simple means, for example if drivers define their own
> version and the new kernel's driver checks whether the
> previous state is from a compatible driver. Then the new
> driver could do a shorter initialization sequence.

There you're clearly getting in the "so complex to maintain that it'll never
work reliably" territory.

> But I'd only do it only in special cases, where for some
> reason the initialization sequence takes longer time and it
> makes sense to share hardware discovery information between
> two versions of the driver. I'm not convinced such a
> mechanism is necessary in the general case.

--
Vojtech Pavlik
Director SUSE Labs


\
 
 \ /
  Last update: 2015-02-24 13:41    [W:0.155 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site