Luck, Tony wrote:
>>This seems crazy to me. Flushing should occur according to the
>>*architecture*, not model-by-model. Even if we happen to get "lucky"
>>on pre-Montecito CPUs, that doesn't justify such ugly hacks. Or you
>>really want to debug this *again* come next CPU?
>
>
> Ditto. The only reason we should ever have model specific checks should
> be to work around model specific errata (e.g. the McKinley Errata #9 code
> in patch.c).
You do have model specific I cache semantics.
Not taking it into account will oblige you to flush in vain for the models
which do not require it. Why do you want to take this option?
Thanks,
Zoltan
On 8/1/07, Zoltan Menyhart <[email protected]> wrote:
> You do have model specific I cache semantics.
> Not taking it into account will oblige you to flush in vain for the models
> which do not require it. Why do you want to take this option?
Given unlimited resources, your proposal makes perfect sense. We
could have a Linux version for Merced, one for McKinley, one for
Madison, etc., etc.
(Un)fortunately, resources are limited and with that constraint in
place, rather than spending lots of time optimizing the kernel for
particular idiosyncrasies of a CPU model, it is generally much better
to optimize it for the things the hardware designers promised us would
stay the same across CPU models (i.e., the "architecture"). Sure, it
may mean that on occasion certain things are slightly slower than they
could be but it does have the decided advantage of letting the
maintainers sleep at night... ;-) Moreover, higher-level
optimizations usually have much higher payoff, so even though you may
do things a bit more slowly at the lowest level, you may end up with a
faster system overall because you were able to spend more time
optimizing at a higher level.
--david