Peter Anvin wrote: > Andreas Herrmann wrote: > > > > It is not equivalent. Usually users check /proc/cpuinfo for their > > CPU features. Deleting that flag is kind of obfuscation. > > > > I guess some time ago people did not care about their "svm" or "vmx" > > flags. Nowadays (e.g. with kvm) some people are quite happy > > if one of those strings occurs in /proc/cpuinfo (and they are quite > > disappointed if this feature was disabled by BIOS). > >
> What you're saying is that you want it to appear in /proc/cpuinfo for > marketing reasons even though it's not usable. Bruellller! So you are saying I am a marketing guy -- wasn't aware of that. Just big fun. > 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. > 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. Regards, Andreas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
