Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758094AbZDXPbn (ORCPT ); Fri, 24 Apr 2009 11:31:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753075AbZDXPbe (ORCPT ); Fri, 24 Apr 2009 11:31:34 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]:34947 "EHLO extu-mxob-1.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752938AbZDXPbe (ORCPT ); Fri, 24 Apr 2009 11:31:34 -0400 Date: Fri, 24 Apr 2009 16:30:18 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.anvils To: Dmitry Adamushko cc: Ingo Molnar , Andrew Morton , Rusty Russell , Andreas Herrmann , Peter Oruba , Arjan van de Ven , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86 microcode: work_on_cpu and cleanup of the synchronization logic In-Reply-To: Message-ID: References: <1240258569.6195.8.camel@earth> <1240344440.5861.10.camel@earth> <1240439073.12721.23.camel@earth> <20090423082704.GD599@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1695 Lines: 39 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/