Messages in this thread | | | Date | Mon, 08 Mar 2010 15:37:10 -0500 | From | Bill Davidsen <> | Subject | Re: [PATCH] x86: Intel microcode loader performance improvement |
| |
Dmitry Adamushko wrote: > On 5 March 2010 18:42, Dimitri Sivanich <sivanich@sgi.com> wrote: >> We've noticed that on large SGI UV system configurations, running >> microcode.ctl can take very long periods of time. This is due to >> the large number of vmalloc/vfree calls made by the Intel >> generic_load_microcode() logic. >> >> By reusing allocated space, the following patch reduces the time >> to run microcode.ctl on a 1024 cpu system from approximately 80 >> seconds down to 1 or 2 seconds. >> >> Signed-off-by: Dimitri Sivanich <sivanich@sgi.com> > > This approach seems reasonable in the scope of the current framework. > > Acked-by: Dmitry Adamushko <dmitry.adamushko@gmail.com> > > However, I think a better approach would be to have some kind of > shared storage for loaded microcode updates. Given that for the > majority of SMP systems all the cpus are normally updated to the very > same new instance of microcode, it should be enough to do a search for > the first cpu, cache the instance of microcode and then reuse it for > others. > The assumption that all CPUs are the same is not always true in practice, people buy a system and don't always fully populate initially, and when they add processors, they have a more recent stepping. So reusing microcode or updating in parallel would add complexity, and 2 sec for 1024 CPUs puts a pretty low upper bound on possible improvement. Does more improvement to a one time small delay justify additional complexity?
Systems that size are probably not booted all that often. Something to consider before putting a lot of effort into it, I think.
-- Bill Davidsen <davidsen@tmr.com> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
| |