From: Prarit Bhargava <prarit@redhat.com>
To: Ming Lei <ming.lei@canonical.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
x86@kernel.org, herrmann.der.user@googlemail.com,
tigran@aivazian.fsnet.co.uk
Subject: Re: [PATCH 2/2] intel_microcode, Fix long microcode load time when firmware file is missing
Date: Mon, 21 Oct 2013 08:26:52 -0400 [thread overview]
Message-ID: <52651D8C.3090203@redhat.com> (raw)
In-Reply-To: <CACVXFVMjEnkk8zYycsk6t4WiWOJ_NT1AKFoK7p5mQnFkw9KE-g@mail.gmail.com>
On 10/21/2013 08:20 AM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava <prarit@redhat.com> wrote:
>> If no firmware is found on the system that matches the processor, the
>> microcode module can take hours to load. For example on recent kernels
>> when loading the microcode module on an Intel system:
>>
>> [ 239.532116] microcode: CPU0 sig=0x306e4, pf=0x1, revision=0x413
>> [ 299.693447] microcode: CPU1 sig=0x306e4, pf=0x1, revision=0x413
>> [ 359.821972] microcode: CPU2 sig=0x306e4, pf=0x1, revision=0x413
>> [ 419.960263] microcode: CPU3 sig=0x306e4, pf=0x1, revision=0x413
>> [ 480.090024] microcode: CPU4 sig=0x306e4, pf=0x1, revision=0x413
>> ...
>> [ 2825.151364] microcode: CPU43 sig=0x306e4, pf=0x1, revision=0x413
>> [ 2885.280863] microcode: CPU44 sig=0x306e4, pf=0x1, revision=0x413
>> [ 2945.410719] microcode: CPU45 sig=0x306e4, pf=0x1, revision=0x413
>> [ 3005.540541] microcode: CPU46 sig=0x306e4, pf=0x1, revision=0x413
>> [ 3065.670405] microcode: CPU47 sig=0x306e4, pf=0x1, revision=0x413
>> ...
>> etc.
>>
>> Similarly there is a 60 second "hang" when loading the AMD module, which
>> isn't as bad as the Intel situation, but it is a noticeable delay in the
>> system boot and can be improved upon.
>>
>> Using request_firmware_nowait() seems more appropriate here and then we
>> can avoid these delays, resulting in very quick load times for the
>> microcode.
>
> request_firmware_nowait() should be a good idea for the problem, but
> why do you pass FW_ACTION_NOHOTPLUG as uevent? It is used now
> by drivers which requires their own user-space applications to handle
> the request by polling the firmware device under sysfs.
Hello Ming,
Oh, I see.
>
> So I am wondering if your microcode case belongs to the above case
> of FW_ACTION_NOHOTPLUG?
You're right. I can easily change that in v2.
>
> And why don't you pass FW_ACTION_HOTPLUG? and you are sure
> that udev isn't required to handle your microcode update request?
>
AFAICT in both cases, udev wasn't required to handle the cpu microcode update.
Both drivers use CMH to load the firmware which removes the need for udev to do
anything. Admittedly maybe I've missed some odd use case but I don't think it
is necessary.
P.
next prev parent reply other threads:[~2013-10-21 12:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-20 21:35 [PATCH 0/2] Improve firmware loading times on AMD and Intel Prarit Bhargava
2013-10-20 21:35 ` [PATCH 1/2] firmware, fix request_firmware_nowait() freeze with no uevent Prarit Bhargava
2013-10-21 12:24 ` Ming Lei
2013-10-21 22:24 ` Prarit Bhargava
2013-10-22 2:35 ` Ming Lei
2013-10-22 23:15 ` Prarit Bhargava
2013-10-23 4:16 ` Ming Lei
2013-10-23 10:36 ` Prarit Bhargava
2013-10-23 12:02 ` Prarit Bhargava
2013-10-23 13:21 ` Ming Lei
2013-10-23 14:08 ` Prarit Bhargava
2013-10-24 1:54 ` Ming Lei
2013-10-24 11:17 ` Henrique de Moraes Holschuh
2013-10-24 12:05 ` Prarit Bhargava
2013-10-20 21:35 ` [PATCH 2/2] intel_microcode, Fix long microcode load time when firmware file is missing Prarit Bhargava
2013-10-21 12:20 ` Ming Lei
2013-10-21 12:26 ` Prarit Bhargava [this message]
2013-10-21 12:32 ` Ming Lei
2013-10-21 14:25 ` Prarit Bhargava
2013-10-22 2:43 ` Ming Lei
2013-10-22 23:16 ` Prarit Bhargava
2013-10-20 22:58 ` [PATCH 0/2] Improve firmware loading times on AMD and Intel Andi Kleen
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=52651D8C.3090203@redhat.com \
--to=prarit@redhat.com \
--cc=herrmann.der.user@googlemail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.com \
--cc=tigran@aivazian.fsnet.co.uk \
--cc=x86@kernel.org \
/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