[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <461567E5.7080905@zytor.com>
Date: Thu, 05 Apr 2007 14:19:33 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: aherrman@...or.de
CC: Andi Kleen <ak@...e.de>, linux-kernel@...r.kernel.org,
andreas.herrmann3@....com
Subject: Re: [PATCH] x86: limit mwait_idle to Intel CPUs
aherrman@...or.de wrote:
>
>> The ones in /proc/cpuinfo are cooked values anyway; there is plenty of
>> history to that effect.
>
> I don't know this history. And I don't care.
> I thought /proc/cpuinfo should show an (almost) complete list
> of CPU features. If this is not the case it's a pity.
>
It's a list of features which are implemented and working, as far as
they make sense. In other words, it's *Linux* concept of the feature
set of the CPU.
>> I would agree with Andi that if as far as Linux is concerned mwait is
>> unusable on AMD Fam10 processors, then the CPU detection code should
>> turn this bit off on AMD Fam10 processors.
>
> And finally I was not aware that you and Andi think of monitor/mwait
> as a synonym for Intel's native C-States.
>
> So I guess, what you really want is that for AMD CPUs the
> monitor-flag (aka native C-state-flag) gets removed.
>
> And if somedays another use case for monitor/mwait appears, the flag
> has to be reintroduced for AMD CPUs.
>
> Fine with me.
> The only drawback is that Andi's idea of idle=mwait wouldn't make
> sense anymore.
Well, if there is use for the AMD implementation of monitor/mwait, then
that's a different situation, and probably would call for multiple
feature bits.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists