On Mon, May 10, 2010 at 2:55 PM, Robert Richter <robert.richter@...> 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 :)