Re: [PATCH 2/2] intel_microcode, Fix long microcode load time whenfirmware file is missing

[Prarit Bhargava]

On 10/21/2013 08:20 AM, Ming Lei wrote:
> On Mon, Oct 21, 2013 at 5:35 AM, Prarit Bhargava <prarit@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/