Linux 5.7でintel_pstateのHWPの挙動が変わっていた

自鯖のProxmox VEを6から7に上げたら、アイドル時の消費電力が上がったような気がする。ハードウェア構成が少し変わってたりもするので何とも言えないところだが、IPMIで見る限り増えているのは確か。

あれこれ試してみたところCPUのスケーリングガバナーの挙動が変わっていた。そして、そもそもCPUドライバとしてintel_pstateではなくintel_cpufreqが使われていた。

# cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq　★これ
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.20 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

同じ環境でPVE 6の時はintel_pstateが使われていたハズなんだけどなぁ。dmesgを見ると、intel_pstateが採用されている雰囲気だが、“HWP not enabled”の一文も気になるところ。

# dmesg | grep intel_pstate
[    2.020574] intel_pstate: HWP not enabled
[    2.020580] intel_pstate: Intel P-state driver initializing

答えはArchiWikiとintel_pstateのドキュメントに書いてあった。HWP (Hardware P-States)が使えないCPUではintel_pstateはPassive Modeとして動作し、ドライバとしてintel_cpufreqが使われるとのこと。お前かー!!

Linuxカーネルバージョン5.8¹⁾でのintel_pstateの改修により、この挙動に変わったらしい。実際、v5.7とv5.8のソースを見比べると、確かにそのような変更が加えられている。

話はこれで終わらずv5.9において、EPP (Energy Performance Preference)を持たないCPUをHWP制御から除外するコードがわざわざ追加されている。HWPはSkylakeからの実装とされているが、実際はBroadwell-EPで初期実装が行われているらしく、現に前述のv5.7コードではHWPを使うようになっている。

自鯖のCPUはまさにBroadwell-EPなXeonなので、見事に該当しているというワケだった。

強制的にアクティブモードにすることもできそうだが、どっちがいいんだろうねぇ？更にHWPM (Hardware Power Management)を使って、完全にハードウェア任せにするという選択肢もあるし悩ましいところ。

(2022-02-21 追記)

うちのマシンの場合アイドル時の消費電力は、やはりアクティブモードの方が気持ち低いようだ。

アクティブモードとパッシブモードの切り替えは/sys/devices/system/cpu/intel_pstate/statusに、それぞれactiveとpassiveを書き込むことで可能。切り替えた場合、スケーリングガバナーの変更もお忘れなく。

# cpupower frequency-info
analyzing CPU 0:
  driver: intel_cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 20.0 us
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.30 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

# echo active > /sys/devices/system/cpu/intel_pstate/status

# cpupower frequency-info 
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency:  Cannot determine or is not supported.
  hardware limits: 1.20 GHz - 3.30 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 1.20 GHz and 3.30 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 1.20 GHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

¹⁾

ArchWikiでは5.7とされているがソースコードを見ると5.8での変更っぽい

permalink · 2022-01-13 21:26 · Decomo · 0 Comments · Tags:

Linux
PC

謹啓　初春のみぎり、いよいよご壮健の由、大慶に存じ上げます。

さて、日頃ご愛顧賜っております弊サイトは、2022年元日を以てクソゲ〜製作所から「のふ処」(のふどころ)に改名することとなりました。併せてドメインもnofu.jpに変わります。中身、コンテンツ、運営方針については従前通りで変更はありません。

要はただのサイト名とドメイン名の変更ですな。理由は以下の通り。

SEO、検索性の問題
ドメインが汚れてきた
地域性の明確化とドメイン名の短縮

decomo.infoは自分の名字と某大手携帯キャリアをもじって付けたものだけど、今となってはSEO的に非常に不利となっている。decomoで検索しても、あっちがサジェストされちゃうんだもの…大企業だしそれこそ重要なインフラを担ってらっしゃるので当然なんですけどね。「クソゲ〜製作所」という名前も同様で、長音符がわりの「〜」は検索エンジンと相性が悪いっぽい。意味のある単語として認識されてないような挙動。波ダッシュ問題も影響してる気がして、非常によろしくない。

この名前は、ゲームプログラマを夢見た高校生の時代に「クソゲ〜製作所というブランドで面白いゲームを作ったら楽しいじゃん」という安直さと、クソゲーは作らないという少しの矜持を込めて付けたものだ。

それから幾年、曲がりなりにも夢は叶い、誰もが知る某有名タイトルなんかにも携わることができたが、ついぞ自分でゲームを作ることはなかった。実のところゲーム業界を離れて既に4年が経つし、ゲームという看板の降ろしどきかなと。

とはいうものの、「のふ処」の“のふ”はクソゲ〜のクを「ク→ノフ→のふ」と変化させ、“処”は製作所の「所」から来ているので全く無関係というわけではない。よりストレートな案として、当初はクソ所（くそじょ/くそどころ）もあったが、いろんな意味で直球過ぎてボツにした。個人的には嫌いではないけど、流石にメールアドレスとして公衆送信するのは憚られるのでｗ

メールアドレスの点では、decomo.infoだと冒頭の有名企業の兼ね合いでバッタもの感が強いし、20年も使ってると情報漏洩やら何やらで汚れて来るんですわ。そうなんですよ、decomo.infoは2002年3月27日に取得してるんで、今年で20年なんですよね。ちょっとビックリですよね。

そんなわけで丁度いい節目でもあるので、4文字と短く、日本発信ってのが明確で、字面と語感が何となく良いnofu.jpに移行する。

これ自体も2018年頃から考えていたもので、実際ドメインはその時に取得済み。移行作業は遅々と進まず、むしろ面倒で進める気もなかったのが実情だが、この正月休みでやっちゃおうと、ふと思い立ったが吉日ってなもんで。ついでにページのスタイルも昨今のレスポンシブな感じに。

本年もよろしくお願いいたします。

permalink · 2022-01-01 00:00 · Decomo · 0 Comments · Tags:

PCIe 4.0なNVMe SSD、Samsung PM9A3 1.92TB (MZ1L21T9HCLS-00A07)が某所で2万円ちょいで売られていた。読み書き量が1520465GB≒1.5ペタバイトという代物で、相当にアレなブツではあるものの、 2TBのPCIe Gen4のNVMe SSDとしてはかなりの安値。PM9A3はエンタープライズ向けのSSDで1DWPDで5年の耐久性が謳われており、換算すると3504TBWとなる。仕様上の寿命は半分以上残っていることになるし、PS5用にちょうどいいんじゃね？ってことで買っちゃった。

お決まりのS.M.A.R.T.情報とベンチマーク結果。

読み書き量のわりに起動回数と時間が極端に少ない。耐久検査に使われたブツの流○品とか？1.5PBで残寿命88%ってことは、理論上は12.5PB書き込めることになる。

ベンチはPCIe 3.0接続であることに注意。うちにはまだPCIe 4.0なPCは無いのだ。

CrystalDiskMark

プロファイル

結果

デフォルト

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  3443.566 MB/s [   3284.0 IOPS] <  2433.85 us>
  SEQ    1MiB (Q=  1, T= 1):  2542.130 MB/s [   2424.4 IOPS] <   412.00 us>
  RND    4KiB (Q= 32, T= 1):   813.802 MB/s [ 198682.1 IOPS] <   155.75 us>
  RND    4KiB (Q=  1, T= 1):    57.317 MB/s [  13993.4 IOPS] <    71.17 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  2091.937 MB/s [   1995.0 IOPS] <  3900.20 us>
  SEQ    1MiB (Q=  1, T= 1):  1936.994 MB/s [   1847.3 IOPS] <   539.93 us>
  RND    4KiB (Q= 32, T= 1):   471.135 MB/s [ 115023.2 IOPS] <   268.97 us>
  RND    4KiB (Q=  1, T= 1):   176.707 MB/s [  43141.4 IOPS] <    21.27 us>

Profile: Default
   Test: 1 GiB (x5) [D: 0% (0/1788GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2021/12/13 21:20:40
     OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64)
Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/Default)

NVMe SSD

-----------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  3466.937 MB/s [   3306.3 IOPS] <  2417.09 us>
  SEQ  128KiB (Q= 32, T= 1):  3523.463 MB/s [  26881.9 IOPS] <  1189.22 us>
  RND    4KiB (Q= 32, T=16):  2202.203 MB/s [ 537647.2 IOPS] <   656.41 us>
  RND    4KiB (Q=  1, T= 1):    55.227 MB/s [  13483.2 IOPS] <    73.86 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  2102.285 MB/s [   2004.9 IOPS] <  3944.41 us>
  SEQ  128KiB (Q= 32, T= 1):  2128.834 MB/s [  16241.7 IOPS] <  1963.64 us>
  RND    4KiB (Q= 32, T=16):  1609.719 MB/s [ 392997.8 IOPS] <  1070.17 us>
  RND    4KiB (Q=  1, T= 1):   121.218 MB/s [  29594.2 IOPS] <    33.34 us>

Profile: Default
   Test: 1 GiB (x5) [D: 0% (0/1788GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2021/12/13 21:03:31
     OS: Windows Server 2016 Server Standard (full installation) [10.0 Build 14393] (x64)
Comment: SAMSUNG PM9A3 1.92TB (PCIe 3.0/M.2/NVMe SSD)

ATTO Disk Benchmark
MB/s	IOPS

なお、ベンチ中はS.M.A.R.T.読みで80℃近くまで上がることを確認。それなりに冷却に気を使った方が良さそう。

で、肝心のPS5はというと、使えませんでした＼(＾o＾)／

電源を入れると画面は真っ暗のままで、光学ドライブがガチャガチャ鳴る→鎮まる→鳴る→鎮まる…という状態を延々と繰り返す。状況的に途中でリセットがかかって再起動を繰り返してるような感じ。

別のPCIe 3.0なSSDで試すと「拡張スロットに装着されたM.2 SSDは使用できません。」の画面がちゃんと出たので、PS5本体は正常、何らかの理由でPM9A3が使えないっぽい。残念賞。

この微妙なPM9A3の処遇はどうしようかな…。

（2022-02-21 追記）

PS5で使えないのは、PS5のM.2スロットの電流供給能力の問題っぽい？下表は各SSDの電流値をまとめたもの。値は手元の現物SSDやネット上の画像から拾った。

SSD	電圧/電流	使用可否	備考
PM9A3 1.92TB	3.3V / 4.3A	×	起動せず
PM9A1 2TB	3.3V / 2.8A	○	使えてるっぽい
980 PRO 2TB	3.3V / 2.9A	○
FireCuda 530 4TB	3.3V / 3.0A	○
FireCuda 530 2TB	3.3V / 2.9A	○
PG4VNZ 2TB	？	○
PG3VNF 1TB	？	○
SN700 250GB	3.3V / 2.8A	△	PCIe 3.0なので使えないが起動はする

こうしてみると、PM9A3が頭一つ飛びぬけているのが分かる。

M.2規格上の定義は探し出せなかったが、何となく最大電力は10W、3.3Vで3Aあたりが上限っぽいように見える。PM9A3に電力制限かければ動くかもしれないけど、突入電流の問題のような気もする。ごついコンデンサ7個（刻印見る限り47μF？）を除去すればワンチャンあるかも？知らんけど。

permalink · 2021-12-27 04:57 · Decomo · 0 Comments · Tags:

Supermicroのマザーボードでファンの回転数をIPMI経由で制御するには、以下のコマンドを投げつければよい。

# 制御モードをFullにする
ipmitool raw 0x30 0x45 0x01 0x01

# "system"ゾーンの回転数を37.5%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x24

# "peripheral"ゾーンの回転数を25%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x16

まず、ファンの制御モードを“Full”にする必要がある。他のモード（Optimalとか）だと、その設定の方が優先されるとのこと。その後、ゾーン毎に回転数を設定してやる。

2～3つ目のipmitoolで送っているバイト列のうち、最後がファンのデューティー比、後ろから2番目がゾーン番号を表す。ゾーンのsystemとperipheralは、マザボのFAN用コネクタFan1系列とFanA系列に対応していると思われるが確認したわけではないので間違ってるかも。

デューティー比は0x00～0x64の64ステップとされている。でも、16進数なんだから0～100なんじゃないの？という気が…ま、ともかく0x00が最小で0x64がフル回転だそうなので、こまけぇこたぁいいんだよ！

実際のところ、Optimalで割とイイ感じに制御してくれるんだけど、ファンによってはデューティー比低すぎて止まっちゃうことがあるんですよね。で、ファン停止エラーが検出される→フル運転→エラーが止まる→デューティー比下がる→ファンが止まる→…の無限ループになるという。

この場合ipmitool sensor threshで最低回転数のスレッショルドを調整するのが定石。うちでは設定値が悪いのか、上手く動いた試しがない。

ファン制御やスレッショルドを弄ってにっちもさっちも行かなくなったら、ipmitool mc reset coldでBMCをリセットしてやればおｋ。

permalink · 2021-12-10 20:16 · Decomo · 0 Comments · Tags:

SSL証明書の期限が切れた状態でcertbot renewを行うと、ApacheプロセスのCPU利用率が100%となりハング状態になるっぽい。apachectlで止めようとしても（弊鯖はご存じのとおりFreeBSDなのでservice apache24 stopだが）、応答が返ってこずkillせざるを得ないという状況。環境は以下のとおり。

FreeBSD 13.0-RELEASE-p4
Apache 2.4.51
certbot 1.21.0
certbot-apache 1.21.0
Python 3.8.12
webrootモードで運用

weekly_certbot_enableでもって週次で証明書の確認＆更新が行われるはずなのに、なんで切れてるの？そもそも期限切れになったからと言って、なんでhttpdがハング状態になるの？と疑問は尽きないのだが、ひとまず脇に置いといて、この状況に陥ったらcertbot certonlyを使って手動で証明書を更新してやる。

# certbot certonly --webroot -w /path/to/document_root -d example.com

証明書更新後、certbot renewでhttpdが暴走しないことを確認する（renewが正常に終われば暴走はしてない。）

それにしても原因は何なんだろうなー。以前、同様の状況が発生した時は、apacheやモジュールの更新を行っていたのでバイナリ間の何らかの不整合くらいで流したが、たぶん今回と同じ原因だったんだろう。さらにその以前は正しく動いていたような気がしなくもない（結構期限切れをやらかしていたので確証が持てない）ので、よくわかりません。

詳しい方教えてください。

(2021-12-24 追記)

確証はないけど、証明書更新後にapache reloadをしておらず、新しい証明書がapacheに認識されてないのが原因な気がする。

FreeBSDフォーラムの投稿のように、証明書更新後のフックスクリプトでリロードしてやれば解決しそうな気がする。

/usr/local/etc/letsencrypt/renewal-hooks/deploy/reload_apache24.sh

#!/bin/sh
service `echo $0|sed -e 's/.*\/\(.*\)_\(.*\).sh/\2 \1/'`

パッと見「なんじゃこりゃ？」ってシェルスクだが、自身のファイル名をsedで切り出しservice apache24 reloadを実行するという、実に巧妙な仕組みだ。引用元のフォーラムでは、同様にdovecotやpostfixの証明書更新も行っていた。中身同じでファイル名を変えればいいだけとは、よく思いつくものだ。