From: "H. Peter Anvin" <hpa@zytor.com>
To: Rene Herman <rene.herman@keyaccess.nl>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Adrian Bunk <bunk@kernel.org>, Yinghai Lu <yhlu.kernel@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel <linux-kernel@vger.kernel.org>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
Pavel Machek <pavel@suse.cz>
Subject: Re: 2.6.26, PAT and AMD family 6
Date: Wed, 07 May 2008 15:57:52 -0700 [thread overview]
Message-ID: <482233F0.7040000@zytor.com> (raw)
In-Reply-To: <48221AE3.6020602@keyaccess.nl>
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
next prev parent reply other threads:[~2008-05-07 22:59 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-07 1:48 2.6.26, PAT and AMD family 6 Rene Herman
2008-05-07 2:39 ` Yinghai Lu
2008-05-07 12:46 ` Undocumented and duplicated code Adrian Bunk
2008-05-07 13:14 ` Rene Herman
2008-05-07 20:52 ` 2.6.26, PAT and AMD family 6 Thomas Gleixner
2008-05-07 20:59 ` Pavel Machek
2008-05-07 21:10 ` Rene Herman
2008-05-07 21:41 ` Thomas Gleixner
2008-05-07 21:46 ` Adrian Bunk
2008-05-07 22:08 ` Thomas Gleixner
2008-05-07 22:29 ` Pavel Machek
2008-05-07 22:04 ` Rene Herman
2008-05-07 22:23 ` Rene Herman
2008-05-07 22:31 ` Yinghai Lu
2008-05-07 22:57 ` H. Peter Anvin [this message]
2008-05-08 0:02 ` Rene Herman
2008-05-08 0:03 ` H. Peter Anvin
2008-05-08 0:10 ` Rene Herman
2008-05-08 0:19 ` Linus Torvalds
2008-05-08 0:28 ` Rene Herman
2008-05-08 1:57 ` [PATCH] x86: introduce a new Linux defined feature flag for PAT support Rene Herman
2008-05-08 1:58 ` Linus Torvalds
2008-05-08 2:11 ` H. Peter Anvin
2008-05-08 2:17 ` Rene Herman
2008-05-08 2:24 ` Linus Torvalds
2008-05-08 2:28 ` H. Peter Anvin
2008-05-08 12:49 ` Thomas Gleixner
2008-05-08 13:08 ` Ingo Molnar
2008-05-08 16:44 ` H. Peter Anvin
2008-05-08 13:11 ` Adrian Bunk
2008-05-08 13:33 ` Thomas Gleixner
2008-05-08 14:44 ` Rene Herman
2008-05-08 14:53 ` Thomas Gleixner
2008-05-08 16:48 ` H. Peter Anvin
2008-05-08 16:53 ` Rene Herman
2008-05-08 2:04 ` [PATCH] x86: enable PAT support on AMD Duron model 7 Rene Herman
2008-05-08 2:08 ` Arjan van de Ven
2008-05-08 2:12 ` Rene Herman
2008-05-08 10:19 ` [PATCH] x86: introduce a new Linux defined feature flag for PAT support Andi Kleen
2008-05-08 12:40 ` Rene Herman
2008-05-08 13:39 ` Andi Kleen
2008-05-08 15:32 ` Alan Cox
2008-05-08 16:51 ` H. Peter Anvin
2008-05-08 0:21 ` 2.6.26, PAT and AMD family 6 Thomas Gleixner
2008-05-08 0:30 ` Rene Herman
2008-05-08 0:15 ` Linus Torvalds
2008-05-08 0:31 ` H. Peter Anvin
2008-05-08 10:14 ` Andi Kleen
2008-05-08 16:43 ` H. Peter Anvin
2008-05-07 21:23 ` Adrian Bunk
2008-05-07 21:54 ` Thomas Gleixner
2008-05-07 22:09 ` Adrian Bunk
2008-05-07 22:14 ` Pavel Machek
2008-05-07 22:22 ` Yinghai Lu
2008-05-07 22:37 ` Pavel Machek
2008-05-07 22:40 ` Yinghai Lu
2008-05-07 23:02 ` Pavel Machek
2008-05-07 23:02 ` Thomas Gleixner
2008-05-07 23:10 ` Pavel Machek
2008-05-07 23:46 ` Thomas Gleixner
2008-05-07 22:23 ` Yinghai Lu
2008-05-07 22:39 ` Pavel Machek
2008-05-07 22:45 ` Yinghai Lu
2008-05-07 23:06 ` Pavel Machek
2008-05-07 23:01 ` H. Peter Anvin
2008-05-07 22:26 ` Yinghai Lu
2008-05-07 22:30 ` Rene Herman
2008-05-07 22:58 ` Thomas Gleixner
2008-05-07 13:00 ` Rene Herman
2008-05-07 13:42 ` Arjan van de Ven
2008-05-07 14:09 ` Rene Herman
2008-05-07 14:24 ` Arjan van de Ven
2008-05-07 19:08 ` Rene Herman
2008-05-07 22:17 ` Arjan van de Ven
2008-05-07 19:39 ` Daniel Hazelton
2008-05-07 20:06 ` Rene Herman
2008-05-07 20:16 ` Yinghai Lu
2008-05-07 20:18 ` Yinghai Lu
2008-05-08 4:06 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2008-05-07 20:44 matthieu castet
2008-05-07 20:46 ` matthieu castet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=482233F0.7040000@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pavel@suse.cz \
--cc=rene.herman@keyaccess.nl \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yhlu.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox