目次: RISC-V
たまにRISC-V向けのQEMUの動きを見たいときがあって、デバッグビルドをするのですが、やり方を忘れがちなのでメモしておきます。
$ mkdir build $ cd build $ ../configure --target-list=riscv32-softmmu,riscv32-linux-user,riscv64-softmmu,riscv64-linux-user \ --disable-docs --enable-debug ... qemu 5.2.50 Install prefix: /usr/local BIOS directory: share/qemu firmware path: /usr/local/share/qemu-firmware binary directory: bin library directory: lib module directory: lib/qemu libexec directory: libexec include directory: include config directory: /usr/local/etc local state directory: /usr/local/var Manual directory: share/man Doc directory: /usr/local/share/doc ... thread sanitizer: NO rng-none: NO Linux keyring: YES FUSE exports: NO FUSE lseek: NO Subprojects libvhost-user: YES Found ninja-1.10.1 at /usr/bin/ninja $ ninja
ビルドが成功するとbuildディレクトリ以下にqemu-system-riscv32やqemu-system-riscv64が生成されているはずです。
目次: Zephyr
開発用のマシンではDebian Testingを使っているのですが、久しぶりにdist-upgradeしたところPython 3.8が消えてしまいました。Python 3.9に移行したみたいです。
アップデート時は「そうなんだ、3.9になったんだな。」くらいの認識でスルーしまいたが、Zephyrを使おうとしたら異変に気づきました。なんとZephyr SDKのGDBが動きません。どうしてこうなった。
$ riscv64-zephyr-elf-gdb riscv64-zephyr-elf-gdb: error while loading shared libraries: libpython3.8.so.1.0: cannot open shared object file: No such file or directory
Debianは元々Zephyr SDKのサポート範囲に入っていない(Ubuntuのみ)ですし、Debian Testingなんてサポートされるはずがないので、自力で解決する必要があります。
Zephyr SDKのビルド手順は簡単ですが、Debian Testingだとうまくいきません。
$ git clone https://github.com/zephyrproject-rtos/sdk-ng $ cd sdk-ng $ ./go.sh riscv64 ./go.sh: 行17: python: コマンドが見つかりません
Pythonが見つからず怒られます。Debian Testingは /usr/bin/pythonがなくなったため、go.shのpythonをpython3に書き換えてあげると動きます。他にもPython 3.8を想定している箇所があるので、Python 3.9に直します。
diff --git a/configs/riscv64.config b/configs/riscv64.config
index 295f2c0..a9fc301 100644
--- a/configs/riscv64.config
+++ b/configs/riscv64.config
@@ -46,5 +46,5 @@ CT_CC_LANG_CXX=y
CT_CC_GCC_LIBSTDCXX_NANO=y
CT_DEBUG_GDB=y
CT_GDB_V_9_2=y
-CT_GDB_CROSS_PYTHON_BINARY="python3.8"
+CT_GDB_CROSS_PYTHON_BINARY="python3.9"
CT_GDB_CROSS_BUILD_NO_PYTHON=y
diff --git a/go.sh b/go.sh
index e5442fa..7a45fd8 100755
--- a/go.sh
+++ b/go.sh
@@ -14,7 +14,7 @@ fi
COMMIT="d7da3a9c7f0f3a90bb4c71b91aea6cbc2471a541"
GITDIR=${PWD}
-JOBS=$(python -c 'import multiprocessing as mp; print(mp.cpu_count())')
+JOBS=$(python3 -c 'import multiprocessing as mp; print(mp.cpu_count())')
unameOut="$(uname -s)"
unameMachine="$(uname -m)"
SDKはbuild/output以下に生成されます。RISC-V 64であればbuild/output/riscv64-zephyr-elfです。生成されたバイナリが動くか確かめましょう。
$ cd build/output/riscv64-zephyr-elf/bin $ ./riscv64-zephyr-elf-gdb Segmentation fault
SEGVで死にました。うーん、だめそうですね……。次回以降、直せないかトライします。
目次: Windows
Windowsで「コミット済み」(=仮想メモリの合計)の値を求める方法がさっぱりわかりません。タスクマネージャーの「パフォーマンス」タブには下記のように値が表示されています。
しかしタスクマネージャーの「詳細」タブに表示される、各プロセスのコミットサイズ(=仮想メモリサイズのことらしい)を足しても全く足りません。どういうこと??
コミットサイズが全然信用できない例を挙げれば、AMDのRadeonドライバ関連でAMDRSServ.exeというプロセスがいます。このプロセスをタスクマネージャーで見ると「5MBしか使ってないよ」とおっしゃっています。
ところがプロセスを強制終了させると、突然700MBほど(6.2GB → 5.5GB)仮想メモリが解放されます。700MBも使っているプロセスはありませんでしたが、700MBどこから来た?意味不明ですね。
たぶんカーネル側というかドライバ内で仮想メモリをでかく取ると「コミット済み」と「各プロセスのコミットサイズの合計」の乖離が激しくなるんじゃないか?と予想していますが、調べ方がわかりません。
Windowsを使っていて仮想メモリが枯渇するような事態に陥り、調べる必要が出てきたとしても、タスクマネージャーの表示してる「コミットサイズ」は全然信用できないってことです。ひどい作りだなあ、もう。
新年早々、WindowsとLinuxのメモリ割り当て戦略の基本的な違いをすっかり忘れていて、ひどい目に合いました。
症状としてはSteamでゲームをしてると頻繁にゲームが落ちたり、ブラウザがクラッシュします。
疑った順に、
仮想メモリの枯渇でした。Windowsは仮想メモリを物理メモリ+ページングファイルの合計量までしか割り当てません。私の環境は物理メモリ16GB+ページングファイル1GBに切り詰めていたため、仮想メモリは17GBまでしか確保できません。
ゲーム+ブラウザを起動すると仮想メモリの消費量が17GBを超えるときがあります。仮想メモリの割り当て量が上限ギリギリに達して、ゲームもしくはブラウザの運が悪い方が、仮想メモリを要求すると、割り当てに失敗します。
するとNULLポインタが返り、NULLポインタにアクセスしてゲームorブラウザがクラッシュしてしまうようです。誰一人として、仮想メモリの割り当て失敗を想定せんの?誰か1人くらいVirtualAlloc() が失敗したって教えてくれても良いのに……。
ページングファイルを適当に増やせば(とりあえず16GBくらいにした)安定しました。
気づいたきっかけはゲーム(Cities: Skylines)のクラッシュダンプです。
エラーログを見るとpaging fileの空きが1MBしかありません。Windowsではこれは仮想メモリの空きを表すそうです。これを知らなかったがために、全然関係ないドライバとか熱暴走を疑い、遠回りしてしまいました。
タスクマネージャーで「コミット済み」の値をチェックすると、仮想メモリの使用量がわかります。これがゲーム+ブラウザで17GBを超えていました。
ダメ押しで、下記のようなVirtualAlloc() APIを呼んで仮想アドレスを大量にガメる(物理メモリはほぼ消費しない)プログラムを書いて、わざと仮想メモリだけを枯渇させました。
#include <cstdio>
#include <cstdlib>
#include <windows.h>
#define CNT 16
int main()
{
const size_t s = 1024 * 1024 * 1024;
char buf[1024], *pb;
void *p[CNT];
for (int c = 0; c < CNT; c++) {
p[c] = VirtualAlloc(NULL, s, MEM_COMMIT, PAGE_READWRITE);
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, buf, sizeof(buf) - 1, NULL);
printf("%s\n", buf);
pb = (char*)p[c];
for (size_t i = 0; i < s / 8192; i++)
pb[i] = (char)i;
}
for (int c = 0; c < CNT; c++)
VirtualFree(p[c], s, MEM_DECOMMIT);
return 0;
}
この状態でゲームを動かすと容易に同じクラッシュが起こせます。というわけで仮想メモリの枯渇で確定と判断しました。
WindowsとLinuxの仮想メモリ割り当て戦略は全く違うのに、同じノリでWindowsのページングファイルを削ってしまったことですね……。一応、違いは知っていたんですが、行動に活かせず思い切りハマりました。
Windowsは仮想メモリ割当てが保守的です。仮想メモリの割り当て上限=物理メモリ+ページファイルの合計となります。
Linuxは仮想メモリの割り当て上限>物理メモリ+スワップファイルの合計となります(over commitment)。
WindowsとLinuxのメモリ割り当て戦略は、利点と欠点が逆になるだけで、どっちもどっちです。
今回の教訓をおさらいすると、Windowsを使っているのに、Linuxと同じノリでページファイルを1GBとか小さいサイズに削ると、速攻で仮想メモリが枯渇してひどい目に合うんでやめようね!ってことです。
記事以外の表示(リンクとか編集ボタンとか)が縦に並んでいて、横長のディスプレイで見たときに邪魔なので、ちょっとだけデザインを変えて縦方向の長さを詰めました。
デザインはあまり詳しくないですが、もっと文字が読みやすくなるようにするにはどうしたら良いんでしょうね……?
年末の帰省チケットを解約したとき(2020年12月17日の日記参照)に価格が激変していたことが気になったので、年末年始の羽田→千歳便の各チケットの価格をプロットしてみました。
どうやらチケットの種類に関係なく、最後に付いているアルファベットで価格帯が決まるようです。Aが一番高くて、B, C, D, ... と安くなっていくようです。10月に予約したSUPER VALUE 75 Hが、今日予約できるVALUE 3 Jより高くなるのはこれが理由でした。
ANAの予約システムは、遠い予約日(1/Mくらい)だと、空席予測を強気に出すのかやや割高の運賃設定をしています。
くらいかな?早朝便、深夜便などは1ランク安くなりがちです。しかし、搭乗日が近づいて(増発を決めてしまった12/30など)、誰も乗らないことに気づき始めると、未だかつて見たことない安さのチケットが出現します。
こんな感じですね。安いなあ。
遠い予約日が強気の価格になるのは、SUPER VALUEでも傾向が一緒のようです。SUPER VALUEの予約日は最短でも21日後と、必然的に遠くなるため、COVID-19の状況下ですと、予約日が遠いSUPER VALUEの方がかえって割高で買ってしまう可能性が高いです。
例えば、一番近いSUPER VALUEの予約日は21日後の1/10です。ラインナップはVALUE 3 H, VALUE 1 G, SUPER VALUE 21 J辺りで、今この瞬間はSUPER VALUE 21 Jが一番安く見えますが、1/10はおそらく誰も乗りません(帰省ラッシュがない以上、Uターンラッシュも起きない)から、1/3くらいまで待てば、VALUE 3 Kとかが登場して、SUPER VALUE 21 Jの価格を下回ると思います。
しかも今は「あんしん変更キャンペーン」があるので、SUPER VALUE 21 Jで予約して払い込んでしまい、年始に安い便があれば切り替え、払い戻しを受ければノーリスクで安く乗れるはずです。
未だかつて年末の羽田→千歳便がこんな低価格で投げ売りされたことはありません。どれだけぼったくっても、皆が渋々乗るので「ドル箱路線」と称されたほどです。
10年来、散々、羽田→千歳便でボラれてきた身としては、今年は流石のANAもぼったくりはできなかったか……と思いました。けどまあCOVID-19に関しては同情しかなくて、乗れる機会があったら飛行機乗って応援したいですね。九州辺りに旅行に行きたいな〜。
「あんしん変更キャンペーン」はただでさえ客足が遠のく中、安く乗られ、割安で解約され、ANAとしては散々でしょう。
逆にこっちはあまり同情してません。飛行機の割引制度は縛りが多くて理不尽です。今の方が素直だし普通です。是非、このまま続けて欲しいですね。
メモ: 技術系?の話はFacebookから転記しておくことにした。いろいろ修正。
< | 2021 | > | ||||
<< | < | 01 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | 1 | 2 |
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 | - | - | - | - | - | - |
合計:
本日: