私はLinuxカーネルを Intel Core 2 Quad (Yorkfield)プロセッサ用に調整しており、dmesg
からの次のメッセージに気付きました。
[ 0.019526] cpuidle: using governor menu
[ 0.531691] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 0.550918] intel_idle: does not run on family 6 model 23
[ 0.554415] tsc: Marking TSC unstable due to TSC halts in idle
PowerTopには、パッケージと個々のコアに使用されている状態C1、C2、C3のみが表示されます。
Package | CPU 0
POLL 0.0% | POLL 0.0% 0.1 ms
C1 0.0% | C1 0.0% 0.0 ms
C2 8.2% | C2 9.9% 0.4 ms
C3 84.9% | C3 82.5% 0.9 ms
| CPU 1
| POLL 0.1% 1.6 ms
| C1 0.0% 1.5 ms
| C2 9.6% 0.4 ms
| C3 82.7% 1.0 ms
| CPU 2
| POLL 0.0% 0.1 ms
| C1 0.0% 0.0 ms
| C2 7.2% 0.3 ms
| C3 86.5% 1.0 ms
| CPU 3
| POLL 0.0% 0.1 ms
| C1 0.0% 0.0 ms
| C2 5.9% 0.3 ms
| C3 87.7% 1.0 ms
不思議なことに、sysfs
を照会したところ、レガシーacpi_idle
ドライバーが使用されていることがわかりました(intel_idle
ドライバーが表示されることを期待していました)。
cat /sys/devices/system/cpu/cpuidle/current_driver
acpi_idle
カーネルソースコードを見ると、現在の intel_idle ドライバーには、一部のIntelファミリー6モデルがドライバーでサポートされていないことを明確に示すデバッグメッセージが含まれています。
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && boot_cpu_data.x86 == 6)
pr_debug("does not run on family %d model %d\n", boot_cpu_data.x86, boot_cpu_data.x86_model);
intel_idle.c の初期の分岐(2010年11月22日)は、Core 2プロセッサーの予想されるサポートを示しています(モデル23は実際にはCore 2 DuoとQuadの両方をカバーしています)。
#ifdef FUTURE_USE
case 0x17: /* 23 - Core 2 Duo */
lapic_timer_reliable_states = (1 << 2) | (1 << 1); /* C2, C1 */
#endif
上記のコードは2010年12月 commit で削除されました。
残念ながら、ソースコードにはドキュメントがほとんどないため、これらのCPUでのアイドル機能のサポートの欠如に関する説明はありません。
私の現在のカーネル構成は次のとおりです。
CONFIG_SMP=y
CONFIG_MCORE2=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_GOV_LADDER is not set
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_Arch_NEEDS_CPU_IDLE_COUPLED is not set
CONFIG_INTEL_IDLE=y
私の質問は次のとおりです:
intel_idle
でサポートされていない特定のハードウェアの理由はありますか?intel_idle
のサポートを無効にする以外に)このプロセッサファミリの最適なCPUアイドルサポートのためにカーネルを構成するより適切な方法はありますか?コア2CPUの電源状態( "C-states")を調査しているときに、レガシーのほとんどのサポートを実際に実装しましたIntel Core/Core 2プロセッサ。すべての背景情報を含む完全な実装(Linuxパッチ)は、ここに記載されています。
これらのプロセッサについての情報を蓄積していくと、Core 2モデルでサポートされているCステートが、以前のプロセッサと後のプロセッサのCステートよりもはるかに複雑であることが明らかになり始めました。これらはEnhanced C-states(または "CxE")として知られており、パッケージ、個々のコア、およびその他のコンポーネントが含まれます。チップセット(メモリなど)。 intel_idle
ドライバーがリリースされた時点では、コードは特に成熟しておらず、C状態のサポートが競合するいくつかのCore 2プロセッサーがリリースされていました。
Core 2 Solo/Duo C状態のサポートに関する説得力のある情報が 2006年のこの記事 にあります。これはWindowsでのサポートに関連していますが、これらのプロセッサでのハードウェアCステートの堅牢なサポートを示しています。ケンツフィールドに関する情報は実際のモデル番号と矛盾するため、実際には以下のヨークフィールドを参照していると思います。
...クアッドコアIntel Core 2 Extreme(Kentsfield)プロセッサは、5つのパフォーマンスおよび省電力テクノロジーすべてをサポートします—拡張Intel SpeedStep(EIST)、Thermal Monitor 1(TM1)およびThermal Monitor 2(TM2)、古いオンデマンドクロック変調(ODCM)、および拡張C状態(CxE)。拡張停止(C1)状態のみを特徴とするIntel Pentium 4およびPentium D 600、800、900プロセッサと比較して、この機能はIntel Core 2プロセッサ(およびIntel Core Solo/Duoプロセッサ)で拡張されています。 Stop Grant(C2)、Deep Sleep(C3)、Deeper Sleep(C4)を含む、プロセッサのすべての可能なアイドル状態。
2008年のこの記事 は、Core 2 DuoやCore 2 Quadを含む、マルチコアIntelプロセッサーでのコアごとのCステートのサポートの概要を示します(さらに役立つ参考資料が このホワイトペーパーに見つかりましたデルから ):
コアCステートは、ハードウェアCステートです。いくつかのコアアイドル状態があります。 CC1およびCC3。ご存知のように、最新のプロセッサーには複数のコアがあり、最近リリースされたCore Duo T5000/T7000モバイルプロセッサー(一部のサークルではPenrynと呼ばれる)などがあります。私たちがCPU /プロセッサとして考えていたものは、実際にはその横に複数の汎用CPUを持っています。 Intel Core Duoのプロセッサチップには2つのコアがあります。 Intel Core-2 Quadには、プロセッサチップごとにこのようなコアが4つあります。これらの各コアには、独自のアイドル状態があります。これは、1つのコアがアイドル状態になり、別のコアがスレッドの処理に懸命に取り組んでいるため、理にかなっています。したがって、コアC状態は、これらのコアの1つのアイドル状態です。
intel_idle
ドライバーに関する追加の背景情報を提供する インテルの2010プレゼンテーション を見つけましたが、残念ながらCore 2のサポートの欠如を説明していません。
このEXPERIMENTALドライバーは、Intel Atomプロセッサー、Intel Core i3/i5/i7プロセッサー、および関連するIntel Xeonプロセッサー上のacpi_idleに取って代わります。IntelCore2プロセッサー以前はサポートしていません。
上記のプレゼンテーションは、intel_idle
ドライバーが「メニュー」CPUガバナーの実装であることを示しています。これは、Linuxカーネル構成に影響を与えます(つまり、CONFIG_CPU_IDLE_GOV_LADDER
とCONFIG_CPU_IDLE_GOV_MENU
)。ラダーとメニューガバナーの違いは、簡潔に this answer で説明されています。
デルには 役立つ記事 があり、C状態のC0からC6への互換性が記載されています。
モードC1からC3は基本的にCPU内で使用されるクロック信号をカットすることによって機能し、モードC4からC6はCPU電圧を下げることによって機能します。 「拡張」モードでは、両方を同時に実行できます。
Mode Name CPUs
C0 Operating State All CPUs
C1 Halt 486DX4 and above
C1E Enhanced Halt All socket LGA775 CPUs
C1E — Turion 64, 65-nm Athlon X2 and Phenom CPUs
C2 Stop Grant 486DX4 and above
C2 Stop Clock Only 486DX4, Pentium, Pentium MMX, K5, K6, K6-2, K6-III
C2E Extended Stop Grant Core 2 Duo and above (Intel only)
C3 Sleep Pentium II, Athlon and above, but not on Core 2 Duo E4000 and E6000
C3 Deep Sleep Pentium II and above, but not on Core 2 Duo E4000 and E6000; Turion 64
C3 AltVID AMD Turion 64
C4 Deeper Sleep Pentium M and above, but not on Core 2 Duo E4000 and E6000 series; AMD Turion 64
C4E/C5 Enhanced Deeper Sleep Core Solo, Core Duo and 45-nm mobile Core 2 Duo only
C6 Deep Power Down 45-nm mobile Core 2 Duo only
この表(後でいくつかのケースで正しくないことがわかりました)から、Core 2プロセッサーでのC状態のサポートにはさまざまな違いがあったようです(Coreを除くほとんどすべてのCore 2プロセッサーはSocket LGA775であることに注意してください) 2 Socket BGA956およびMerom/PenrynプロセッサーであるSolo SU3500。「Intel Core」Solo/Duoプロセッサーは、Socket PBGA479またはPPGA478のいずれかです。
テーブルの追加の例外が this article で見つかりました:
IntelのCore 2 Duo E8500はCステートC2およびC4をサポートしていますが、Core 2 Extreme QX9650はサポートしていません。
興味深いことに、QX9650はYorkfieldプロセッサ(Intelファミリ6、モデル23、ステッピング6)です。参考までに、私のQ9550SはIntelファミリー6、モデル23(0x17)、ステッピング10で、CステートC4(実験により確認済み)をサポートしていると思われます。さらに、Core 2 Solo U3500のCPUID(ファミリ、モデル、ステッピング)はQ9550Sと同じですが、LGA775以外のソケットでも使用できるため、上記の表の解釈が混乱します。
明らかに、CPUIDは、このプロセッサモデルのC状態のサポートを特定するために、少なくともステッピングまで使用する必要があり、場合によっては不十分である(現時点では未定)。
CPUアイドル情報を割り当てるためのメソッドシグネチャは次のとおりです。
#define ICPU(model, cpu) \
{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_ANY, (unsigned long)&cpu }
ここで、model
は asm/intel-family.h に列挙されています。このヘッダーファイルを調べると、Intel CPUには、Intelファミリー6のモデル番号と一致するように見える8ビットの識別子が割り当てられていることがわかります。
#define INTEL_FAM6_CORE2_PENRYN 0x17
上記から、Intel Family 6、Model 23(0x17)がINTEL_FAM6_CORE2_PENRYN
として定義されています。ほとんどのモデル23プロセッサのアイドル状態を定義するにはこれで十分ですが、上記のようにQX9650で問題が発生する可能性があります。
したがって、最低限、個別のC状態セットを持つプロセッサの各グループをこのリストで定義する必要があります。
Zagacki and Ponnala、Intel Technology Journal12(3):219-227、 2008 Yorkfieldプロセッサが実際にC2およびC4をサポートしていることを示します。また、ACPI 3.0a仕様はC状態C0、C1、C2、およびC3間の遷移のみをサポートしていることも示しているようです。これにより、Linux acpi_idle
ドライバーもC状態の限定されたセット間の遷移に制限されると考えられます。 。ただし、 この記事 は、常にそうであるとは限らないことを示しています。
ACPI Cの状態であり、プロセッサの状態ではないことに注意してください。ACPIC3はHW C6などになる場合があります。
また注意してください:
プロセッサー自体を超えて、C4はプラットフォームの主要なシリコンコンポーネント間の同期化された取り組みであるため、インテルQ45 Expressチップセットは28%の電力改善を実現します。
私が使用しているチップセットは、確かにIntel Q45 Expressチップセットです。
MWAITに関するIntelのドキュメント は簡潔ですが、BIOS固有のACPI動作を確認しています。
MWAIT拡張で定義されたプロセッサー固有のC状態は、ACPI定義のC状態タイプ(C0、C1、C2、C3)にマップできます。マッピング関係は、プロセッサー実装によるC状態の定義に依存し、ACPI定義の_CSTテーブルを使用してBIOSによってOSPMに公開されます。
上記の表( Wikipediaの表 、 asm/intel-family.h および上記の記事と組み合わせる)の私の解釈は次のとおりです。
モデル9 0x09(Pentium M andCeleron M):
モデル13 0x0D(Pentium M andCeleron M):
モデル14 0x0E INTEL_FAM6_CORE_YONAH(Enhanced Pentium M、Enhanced Celeron M orIntel Core):
モデル15 0x0F INTEL_FAM6_CORE2_MEROM(someCore 2 andPentium Dual-Core):
モデル23 0x17 INTEL_FAM6_CORE2_PENRYN(Core 2):
Core 2ラインのプロセッサーのみでのC状態のサポートの多様性の量から、C状態に対する一貫したサポートの欠如がintel_idle
を介してそれらを完全にサポートしようとしない理由であると思われます運転者。 Core 2ライン全体について上記のリストを完全に記入したいと思います。
これは実際には満足のいく答えではありません。それは、不必要な電力がどれだけ使用され、堅牢な省電力を十分に活用しないことによって過剰な熱が生成されたのか(そしてそれでも生成されます) MWAIT C-states だからです。これらのプロセッサで。
Chattopadhyayet al。2018、 Energy Efficient High Performance Processors:Designing for Designing Green High Performance Computing 私が探している特定の動作については注目に値しますQ45 Expressチップセットの場合:
パッケージCステート(PC0-PC10)-コンピューティングドメイン、コアおよびグラフィックス(GPU)がアイドル状態の場合、プロセッサーは、非コアレベルおよびプラットフォームレベルで追加の省電力を実現する機会があります。たとえば、LLCのフラッシュや電源ゲーティングメモリコントローラーとDRAM IO、および一部の状態では、常時オンのパワードメインでその状態が保持されている間、プロセッサー全体をオフにすることができます。
テストとして、以下を linux/drivers/idle/intel_idle.c 127行目に挿入しました。
static struct cpuidle_state conroe_cstates[] = {
{
.name = "C1",
.desc = "MWAIT 0x00",
.flags = MWAIT2flg(0x00),
.exit_latency = 3,
.target_residency = 6,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C1E",
.desc = "MWAIT 0x01",
.flags = MWAIT2flg(0x01),
.exit_latency = 10,
.target_residency = 20,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
// {
// .name = "C2",
// .desc = "MWAIT 0x10",
// .flags = MWAIT2flg(0x10),
// .exit_latency = 20,
// .target_residency = 40,
// .enter = &intel_idle,
// .enter_s2idle = intel_idle_s2idle, },
{
.name = "C2E",
.desc = "MWAIT 0x11",
.flags = MWAIT2flg(0x11),
.exit_latency = 40,
.target_residency = 100,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.enter = NULL }
};
static struct cpuidle_state core2_cstates[] = {
{
.name = "C1",
.desc = "MWAIT 0x00",
.flags = MWAIT2flg(0x00),
.exit_latency = 3,
.target_residency = 6,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C1E",
.desc = "MWAIT 0x01",
.flags = MWAIT2flg(0x01),
.exit_latency = 10,
.target_residency = 20,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C2",
.desc = "MWAIT 0x10",
.flags = MWAIT2flg(0x10),
.exit_latency = 20,
.target_residency = 40,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C2E",
.desc = "MWAIT 0x11",
.flags = MWAIT2flg(0x11),
.exit_latency = 40,
.target_residency = 100,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C3",
.desc = "MWAIT 0x20",
.flags = MWAIT2flg(0x20) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 85,
.target_residency = 200,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C4",
.desc = "MWAIT 0x30",
.flags = MWAIT2flg(0x30) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 100,
.target_residency = 400,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C4E",
.desc = "MWAIT 0x31",
.flags = MWAIT2flg(0x31) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 100,
.target_residency = 400,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.name = "C6",
.desc = "MWAIT 0x40",
.flags = MWAIT2flg(0x40) | CPUIDLE_FLAG_TLB_FLUSHED,
.exit_latency = 200,
.target_residency = 800,
.enter = &intel_idle,
.enter_s2idle = intel_idle_s2idle, },
{
.enter = NULL }
};
intel_idle.c
983行目:
static const struct idle_cpu idle_cpu_conroe = {
.state_table = conroe_cstates,
.disable_promotion_to_c1e = false,
};
static const struct idle_cpu idle_cpu_core2 = {
.state_table = core2_cstates,
.disable_promotion_to_c1e = false,
};
intel_idle.c
1073行目:
ICPU(INTEL_FAM6_CORE2_MEROM, idle_cpu_conroe),
ICPU(INTEL_FAM6_CORE2_PENRYN, idle_cpu_core2),
PXEノードをすばやくコンパイルして再起動すると、dmesg
に次のように表示されます。
[ 0.019845] cpuidle: using governor menu
[ 0.515785] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 0.543404] intel_idle: MWAIT substates: 0x22220
[ 0.543405] intel_idle: v0.4.1 model 0x17
[ 0.543413] tsc: Marking TSC unstable due to TSC halts in idle states deeper than C2
[ 0.543680] intel_idle: lapic_timer_reliable_states 0x2
そして今PowerTOPは示しています:
Package | CPU 0
POLL 2.5% | POLL 0.0% 0.0 ms
C1E 2.9% | C1E 5.0% 22.4 ms
C2 0.4% | C2 0.2% 0.2 ms
C3 2.1% | C3 1.9% 0.5 ms
C4E 89.9% | C4E 92.6% 66.5 ms
| CPU 1
| POLL 10.0% 400.8 ms
| C1E 5.1% 6.4 ms
| C2 0.3% 0.1 ms
| C3 1.4% 0.6 ms
| C4E 76.8% 73.6 ms
| CPU 2
| POLL 0.0% 0.2 ms
| C1E 1.1% 3.7 ms
| C2 0.2% 0.2 ms
| C3 3.9% 1.3 ms
| C4E 93.1% 26.4 ms
| CPU 3
| POLL 0.0% 0.7 ms
| C1E 0.3% 0.3 ms
| C2 1.1% 0.4 ms
| C3 1.1% 0.5 ms
| C4E 97.0% 45.2 ms
私はようやくEnhanced Core 2 C-statesにアクセスしましたが、消費電力に測定可能な低下があるようです-8ノードのメーターの平均が少なくとも5%低いようです(1つのノードが古いカーネルを実行している場合)。 、しかし、私はテストとしてカーネルを再度交換してみます。
C4Eサポートに関する興味深いメモ-My Yorktown Q9550Sプロセッサーは、上記で証明されたように、それ(またはC4の他のサブステート)をサポートしているようです。 Core 2 Q9000プロセッサのIntelデータシート (セクション6.2)はC-states Normal(C0)、HALT(C1 = 0x00)、Extended HALT(C1E = 0x01)、許可の停止(C2 = 0x10)、拡張停止の許可(C2E = 0x11)、スリープ/ディープスリープ(C3 = 0x20)、ディーパースリープ(C4 = 0x30)。この追加の0x31状態とは何ですか?状態C2を有効にすると、C4の代わりにC4Eが使用されます。状態C2を無効にする場合(強制状態C2E)、C4Eの代わりにC4が使用されます。これはMWAITフラグと関係があるのではないかと思いますが、この動作に関するドキュメントはまだ見つかりません。
C1Eの代わりにC1E状態が使用されているように見え、C2Eの代わりにC2が使用され、C4の代わりにC4Eが使用されています。 C1/C1E、C2/C2E、C4/C4Eをintel_idle
と一緒に使用できるかどうか、またはそれらが冗長かどうかは不明です。 Intel Labs Pittsburghによる2010年のこのプレゼンテーション に、遷移がC0-C1-C0-C1E-C0であることを示すメモがあり、さらに次のように述べています。
C1Eは、すべてのコアがC1Eにある場合にのみ使用されます
すべてのコアがC1E状態にある場合にのみ、C1E状態が他のコンポーネント(メモリなど)に入ると解釈されると思います。私はこれをC2/C2EおよびC4/C4E状態に同等に適用するためにも使用します(C4Eは「C4E/C5」と呼ばれますが、C4EがC4のサブ状態であるか、C5がサブ状態であるかはわかりませんC4Eの状態。テストはC4/C4Eが正しいことを示しているようです)。 C2状態をコメント化することでC2Eを強制的に使用できますが、これによりC4Eの代わりにC4状態が使用されます(ここでさらに作業が必要になる場合があります)。うまくいけば、状態C2Eのないモデル15またはモデル23のプロセッサはありません。これらのプロセッサは、上記のコードではC1/C1Eに制限されるためです。
また、フラグ、レイテンシ、およびレジデンシーの値はおそらく微調整される可能性がありますが、Nehalemアイドル値に基づいて知識に基づいた推測を行うだけでうまくいくようです。改善を行うには、さらに多くの資料が必要になります。
これを Core 2 Duo E222 ( Allendale )、a Dual Core Pentium E53 ( Wolfdale )でテストしました。 Core 2 Duo E74 、 Core 2 Duo E84 ( Wolfdale )、 Core 2 Quad Q9550S ( Yorkfield )および Core 2 Extreme QX965 であり、前述の州C2/C2EおよびC4/C4Eの設定を超える問題は見つかりませんでした。
このドライバーの変更の対象外:
私が考えることができる唯一の問題は:
intel_idle
ドライバーは、サブステートのハードウェアサポートに基づいて適切なC1/C1Eを選択するように見えます。2009年のIntelプレゼンテーションから、C状態間の移行(つまり、ディープパワーダウン)に関するスライドを見つけました。
結論として、intel_idle
ドライバーでCore 2がサポートされていないのには本当の理由がないことがわかりました。 「コア2デュオ」の元のスタブコードはCステートC1とC2のみを処理したことは明らかです。これは、CステートC3も処理するacpi_idle
関数よりもはるかに効率が悪かったでしょう。どこを見ればよいかがわかれば、サポートの実装は簡単です。役立つコメントやその他の回答は高く評価されました。Amazonが耳を傾けていれば、小切手の送付先がわかります。
このアップデートは githubにコミット されています。 LKMLにパッチをメールで送信します。
更新:ソケットT/LGA775 Allendale ( Conroe )コアも掘り出すことができました2 Duo E2220、これはファミリー6、モデル15なので、サポートも追加しました。このモデルはCステートC4をサポートしていませんが、C1/C1EおよびC2/C2Eをサポートしています。これは、他のConroeベースのチップ( E4xxx / E6xxx )と、すべてのKentsfieldおよびMerom(Merom-L以外)プロセッサでも機能するはずです。
Update:ようやくMWAITチューニングリソースを見つけました。これ Power vs. Performance の説明とこの Deeper C状態と増加したレイテンシ ブログ投稿には、CPUアイドルレイテンシの識別に関するいくつかの有用な情報が含まれています。残念ながら、これはカーネルにコード化された終了レイテンシのみを報告します(ただし、興味深いことに、プロセッサでサポートされているハードウェアの状態のみ)。
# cd /sys/devices/system/cpu/cpu0/cpuidle
# for state in `ls -d state*` ; do echo c-$state `cat $state/name` `cat $state/latency` ; done
c-state0/ POLL 0
c-state1/ C1 3
c-state2/ C1E 10
c-state3/ C2 20
c-state4/ C2E 40
c-state5/ C3 20
c-state6/ C4 60
c-state7/ C4E 100
(intel_idleのサポートを無効にする以外に)このプロセッサファミリの最適なCPUアイドルサポートのためにカーネルを構成するより適切な方法はありますか?
ACPIを有効にし、acpi_idleが使用されていることを確認しました。私はあなたが有用なカーネル設定オプションを見逃したことを心から疑っています。いつでもpowertop
で可能な提案を確認できますが、おそらくすでにご存知だと思います。
これは答えではありませんが、それをフォーマットしたいと思います:-(。
カーネルソースコードを見ると、現在のintel_idleドライバーには、ドライバーからIntelファミリー6を明確に除外するためのテストが含まれています。
いいえ、それはしません:-)。
id = x86_match_cpu(intel_idle_ids);
if (!id) {
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
boot_cpu_data.x86 == 6)
pr_debug(PREFIX "does not run on family %d model %d\n",
boot_cpu_data.x86, boot_cpu_data.x86_model);
return -ENODEV;
}
if
ステートメントはFamily 6を除外しません。代わりに、if
ステートメントは、デバッグが有効になっているときに、この特定の最新のIntel CPUがintel_idle
でサポートされていないというメッセージを提供します。実際、私の現在のi5-5300U CPUはFamily 6で、intel_idle
を使用しています。
CPUを除外するのは、intel_idle_ids
テーブルに一致するものがないことです。
テーブルを実装するこのコミットに気づきました。削除されたコードには、代わりにswitch
ステートメントが含まれていました。これにより、最も初期のモデルintel_idleが実装された/テストに成功した/ 0x1A = 26であることが簡単にわかるようになります。 https://github.com/torvalds/linux/commit/b66b8b9a4a79087dde1b358a016e5c8739ccf186
これは機会とコストの単なる例になり得るのではないかと思います。 _intel_idle
_が追加されたとき、Core 2 Duoのサポートは計画されていたようですが、完全には実装されていませんでした。おそらく、インテルのエンジニアがそれに取り掛かる頃には、それ以上の価値はありませんでした。方程式は比較的複雑です:_intel_idle
_は、ここでサポートする価値があるように、_acpi_idle
_よりも十分な利点を提供する必要があります。
sourcejedi 's answer が言うように、ドライバーはファミリー6のすべてを除外しません。_intel_idle
_初期化は、CPUの CPUモデル 、基本的にNehalemからKaby Lakeまでのすべてのマイクロアーキテクチャをカバーします。 Yorkfieldはそれよりも古い(そして大幅に異なる— Nehalemはそれ以前のアーキテクチャとは非常に異なる)。ファミリ6テストは、エラーメッセージが出力されるかどうかにのみ影響します。その効果は、エラーメッセージがIntel CPUでのみ表示され、AMD CPUでは表示されないことだけです(Intelファミリ6には、Pentium Pro以降のすべての非NetBurst Intel CPUが含まれています)。
設定の質問に答えるには、_intel_idle
_を完全に無効にすることができますが、そのままにしておいてもかまいません(警告を気にしない限り)。