On Tue 2015-02-24 11:23:29, Ingo Molnar wrote: > What gradual improvements in live upgrade latency am I > talking about? > > - For example the majority of pure user-space process > pages in RAM could be saved from the old kernel over > into the new kernel - i.e. they'd stay in place in RAM, > but they'd be re-hashed for the new data structures.
I wonder how many structures we would need to rehash when we update the whole kernel. I think that it is not only about memory but also about any other subsystem: networking, scheduler, ... > - Hardware devices could be marked as 'already in well > defined state', skipping the more expensive steps of > driver initialization. This is another point that might get easily wrong. We know that the quality of many drivers is not good. Yes, we want to make it better. But we also know that system suspend does not work well on many systems for years even with the huge effort. > - Possibly full user-space page tables could be preserved > over an upgrade: this way user-space execution would be > unaffected even in the micro level: cache layout, TLB > patterns, etc. > > There's lots of gradual speedups possible with such a model > IMO. > > With live kernel patching we run into a brick wall of > complexity straight away: we have to analyze the nature of > the kernel modification, in the context of live patching, > and that only works for the simplest of kernel > modifications. > > With live kernel upgrades no such brick wall exists, just > about any transition between kernel versions is possible. I see here a big difference in the complexity. If verifying patches is considered as complex then I think that it is much much more complicated to verify that the whole kernel upgrade is safe and that all states will be properly preserved and reused. Otherwise, I think that live patching won't be for any Joe User. The people producing patches will need to investigate the changes anyway. They will not blindly take a patch on internet and convert it to a life patch. I think that this is true for many other kernel features. > Granted, with live kernel upgrades it's much more complex > to get the 'simple' case into an even rudimentarily working > fashion (full userspace state has to be enumerated, saved > and restored), but once we are there, it's a whole new > category of goodness and it probably covers 90%+ of the > live kernel patching usecases on day 1 already ... I like the idea and I see the benefit for other tasks: system suspend, migration of systems to another hardware, ... But I also think that it is another level of functionality. IMHO, live patching is somewhere on the way for the full kernel update and it will help as well. For example, we will need to somehow solve transition of kthreads and thus fix their parking. I think that live patching deserves its separate solution. I consider it much less risky but still valuable. I am sure that it will have its users. Also it will not block improving the things for the full update in the future. Best Regards, Petr -- 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/
