From: ebiederm@xmission.com (Eric W. Biederman)
To: "Jan H. Schönherr" <jschoenh@amazon.de>
Cc: Thomas Gleixner <tglx@linutronix.de>, kexec@lists.infradead.org
Subject: Re: [PATCH] kexec: Allow to skip digest calculation for speed
Date: Tue, 06 Feb 2018 16:22:10 -0600 [thread overview]
Message-ID: <87y3k5hi7h.fsf@xmission.com> (raw)
In-Reply-To: <4d45f270-7659-4d64-69a2-a9c448875c02@amazon.de> ("Jan H. \=\?utf-8\?Q\?Sch\=C3\=B6nherr\=22's\?\= message of "Fri, 2 Feb 2018 22:54:22 +0100")
"Jan H. Schönherr" <jschoenh@amazon.de> writes:
> On 02/02/2018 02:42 AM, Eric W. Biederman wrote:
>> Jan H. Schönherr <jschoenh@amazon.de> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
prev parent reply other threads:[~2018-02-06 22:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 23:11 [PATCH] kexec: Allow to skip digest calculation for speed Jan H. Schönherr
2018-02-02 1:42 ` Eric W. Biederman
2018-02-02 21:54 ` Jan H. Schönherr
2018-02-06 22:22 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y3k5hi7h.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=jschoenh@amazon.de \
--cc=kexec@lists.infradead.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox