Re: [Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

["Raj, Ashok" <ashok.raj@xxxxxxxxx>]

Hi Jan

On Tue, May 22, 2018 at 03:26:06AM -0600, Jan Beulich wrote:
> >>> On 22.05.18 at 10:59, <chao.gao@xxxxxxxxx> wrote:
> > Do you think it is acceptable that we just follow linux kernel at present
> > and work out optimizations later?
> 
> In the worst case I could live with it, but I'd be far from happy if so. Sadly
> experience (in general, not with you personally) has told me that if we let
> things go in this way right now, there's a high risk that you'd never follow
> up with the subsequent optimization of the process.

You are right.. but to be fair, the original patch we did was to update all 
cores
at the same time (just limiting no more than one thread in a core do the update)

We scaled it back to be conservative taking feedback from our internal teams.
You are preaching to the choir here :-).. but given that there has been so many
problems in this area, we wanted to be extra safe and take baby steps.

so the optimization is stil in the plan.. 

> 
> Furthermore, in Linux, was the decision to go the presented route really
> taken with KVM and its possibly active guests in mind? Not to speak of
> ordinary applications that may be latency sensitive.

Late load is really an option that i think system/cloud adminstrator would do
based on need. If they have real latency sensitive workloads runing they can 
always
have the option on when to do the live update. At best they can simply update 
initrd
so just in case there is a reboot scheduled it would catch the update. Which is 
the 
2nd most receommended method compared to doing it in the BIOS (most preferred). 
late_load
is the last choice to ucode update.

We can make the duration small, but a stop_machine() is still doing to be 
noticable 
on certain workloads at any scale.

Like someone told me: If you tell "doctor doctor it hurts when i do this"

the recommendation is "Don't do it". :-)

This is a facility that we will improve, but its never going to be perfect for 
all 
conditions. Not recommended by end user and weak at heart.

Cheers,
Ashok


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel