"Jan H. Schönherr" <jschoenh@xxxxxxxxx> writes: > On 02/02/2018 02:42 AM, Eric W. Biederman wrote: >> Jan H. Schönherr <jschoenh@xxxxxxxxx> writes: >> >>> Give the administrator the ability to trade kexec safety for kexec speed >>> by disabling the digest calculation/verification for regular kexecs. >>> >>> The behavior of kexec-on-crash is not touched. >> >> The performance of the digest caculation is acceptable on 386s. Or it >> was years ago when I tested it on a 386. What is the problem you are >> having. >> >> Is there something silly like a cache disable in your configuration? > > Last time I measured, this patch reduced the time until the system is responsive > again after a kexec by about 50 ms to 100 ms in my setups. That seems to be about > the right time for enabled caches, judging from a quick sha256sum on the command > line and the kernel sizes I'm working with. > > These 50 ms to 100 ms are a noticeable fraction of the total kexec time and they > are easy to avoid -- compared to some other time sinks in the Linux > boot process. So just optimization for optimization sake. It fixes no problems and solves no challenges. On a human time scale I don't believe 50ms to 100ms is at all noticable. The option is already there if you don't use the kexec_file syscall. The kexec_file syscall exists because people have setups where signatures are needed on kernels and so can not afford the full generality of the original kexec system call. The use of kexec_file already tells us people of given up full generality for safety. If there is a compelling use case we can talk about this, but right now I don't see what could possibly be compelling about saving a tenth of a second, on a comparatively rare operation. Eric _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
