On Wed, Jul 31, 2019 at 12:50 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Wed, Jul 31, 2019 at 12:40:51PM -0400, Pavel Tatashin wrote: > > On Wed, Jul 31, 2019 at 12:33 PM Mark Rutland <mark.rutland@xxxxxxx> wrote: > > > > > > Hi Pavel, > > > > > > Generally, the cover letter should state up-front what the goal is (or > > > what problem you're trying to solve). It would be really helpful to have > > > that so that we understand what you're trying to achieve, and why. > > [...] > > > > > Here is the current data from the real hardware: > > > > (because of bug, I forced EL1 mode by setting el2_switch always to zero in > > > > cpu_soft_restart()): > > > > > > > > For this experiment, the size of kernel plus initramfs is 25M. If initramfs > > > > was larger, than the improvements would be even greater, as time spent in > > > > relocation is proportional to the size of relocation. > > > > > > > > Previously: > > > > kernel shutdown 0.022131328s > > > > relocation 0.440510736s > > > > kernel startup 0.294706768s > > > > > > In total this takes ~0.76s... > > > > > > > > > > > Relocation was taking: 58.2% of reboot time > > > > > > > > Now: > > > > kernel shutdown 0.032066576s > > > > relocation 0.022158152s > > > > kernel startup 0.296055880s > > > > > > ... and this takes ~0.35s > > > > > > So do we really need this complexity for a few blinks of an eye? > > > > Yes, we have an extremely tight reboot budget, 0.35s is not an acceptable waste. > > Could you please elaborate on your use-case? > > Understanfin what you're trying to achieve would help us to understand > which solutions make sense. An extremely high availability device with an update story utilizing kexec functionality for a faster kernel update and also for being able to preserve some state in memory without wasting the time of copying it to and from a backing storage. We at Microsoft will be using a fleet of these devices. The total reboot budget is less than half a second, out of which 0.44s is currently spent in kexec relocation. Pasha > > Thanks, > Mark.
