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

[Vojtech Pavlik]

On Tue, Feb 24, 2015 at 11:53:28AM +0100, Ingo Molnar wrote:
> 
> * Jiri Kosina <jkosina@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/