Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the synchronization logic

[Hugh Dickins]

On Fri, 24 Apr 2009, Dmitry Adamushko wrote:
> 
> Assumption: most of the CPUs (maybe with an exception of the boot-cpu
> when its ucode is updated by BIOS) upgrade from revisions A to B,
> where A and B are the same for all of them (well, at least B -- the
> most recent one [*]).
> 
> Then why bother loading/traversing firmware (or traversing .dat files)
> for each of them?
> 
> [*] btw., are all CPUs on SMP systems similar wrt model, stepping?

I'm not an authority on these matters, but I think it's true to say:
that's almost always the case in practice, and some vendors refuse to
support combinations of non-identical CPUs; but it's not necessarily
the case.  I think there was a product from one vendor (SGI??) which
most commonly had a mixture.

> 
> Even if not, we could do some caching so that if cpu-2 asks for
> intel-ucode/06-0f-0a and we know that cpu-1 has just done the same and
> still has a proper ucode in its buffer, then we just make a copy.

Okay, but don't spend too much code and ingenuity upon it.  And note
that when Intel get around to it (and the distros have caught up),
they will be moving away from the all-in-one /etc/microcode.dat
MICROCODE_OLD_INTERFACE, to the /lib/firmware/intel-ucode/06-0f-0a
style - so I don't think optimizing .dat read time is worth much.

Indeed, MICROCODE_OLD_INTERFACE is driven by /sbin/microcode_ctl
anyway, I don't think you should be second-guessing what it might
feed you.

Hugh
--
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/