lkml.org 
[lkml]   [2008]   [May]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.26, PAT and AMD family 6
Rene Herman wrote:
> On 07-05-08 22:52, Thomas Gleixner wrote:
>
>>> And why do we need this clear_cpu_cap(c, X86_FEATURE_PAT) and then
>>> manual setting of X86_FEATURE_PAT at all?
>>
>> The reason is to make cpu_has_pat a useful check and to avoid checking
>> cpu vendors, families and models inside of the PAT code. That's a good
>> thing actually, because the PAT code only cares about that cpu_has_pat
>> flag.
>>
>> Clearing it in the cpuinfo is just a cosmetic side effect which does
>> no harm at all.
>
> Oh yes, it does. It makes people unaware that their CPUs _should_ be
> supporting PAT. The thing's not called /proc/kernelinfo for a reason.
>

Okay, that is utter nonsense. /proc/cpuinfo has always been, and will
always be, the CPU *AS THE KERNEL SEES IT*. If you want something else,
use x86info(1).

> And would yelling at people how shuffle in code without (publicly at
> least) addressing one of your fellow arch maintainers objections and
> Pavel's review comments about code duplication without a single line
> of explanation/changelog do?

We did discuss this (over IRC, I'm afraid), and came to the conclusion
that it's too risky to do the proper thing (blacklist) straight out the
gate. Consider it a staged implementation. The reason for this is that
some of the earlier chips have downright frightening errata w.r.t. PAT.
*At this point*, we'd have no reasonable way to filter those bug
reports from the issues with the software itself.

So, one step at a time. PAT is massively overdue in Linux, so it's no
wonder you're anxious about it, but we need a modicum of caution here.

-hpa


\
 
 \ /
  Last update: 2008-05-08 01:01    [W:0.135 / U:0.700 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site