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 live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
