From: John V. <sod...@gm...> - 2010-05-10 19:19:06
|
On Mon, May 10, 2010 at 2:55 PM, Robert Richter <rob...@am...> wrote: > On 10.05.10 14:17:56, John Villalovos wrote: >> I would think we should leave "i386/core_i7" in there, but add in >> "i386/nehalem" so that we could switch the kernel in the future. > > What will be the difference? We should change the cpu strings only if > necessary. Better, we find a way to avoid this strings at all. There > is already "i386/arch_perfmon", maybe this could be extended to be > setup dynamically depending on the model? In my mind the difference is that we wouldn't be doing what we are now, which is using "i386/core_i7" as the identifier for Nehalem microarchitecture processors and have it NOT be the correct identifier for a Core i7-980X processor. The Core i7-980X processor is based on the Westmere microarchitecture and even though it is a Core i7 processor, it is incorrect to have the kernel return "i386/core_i7" for that processor at the moment, because the events for Nehalem and Westmere differ. Now having the oprofile userspace package determine if the processor is supported doesn't seem like a bad idea to me, though I have no ideas at the moment on how to do that or how hard it would be. Maybe having the logic to determine which events list to use should be in the userspace instead of the kernel? The main reason I brought this up as when I posted my patch changing the hex values, I had someone request to add in their Core i7-980X to the "i386/core_i7". I had to explain that yes it is a Core i7, but that since it was Westmere it wasn't the correct for it to go. I guess it isn't "necessary" to change but it does seem a little confusing as it is now. Hopefully I make sense :) Thanks, John |