コグノスケ

不安定なyes

目次: ベンチマーク

昔（2017年6月14日の日記参照）yesの速度を測ったりして遊んでいましたが、改めてRyzen 7 2700でyes | pv > /dev/nullを実行してみたところ、出力速度が不安定です。

GNU yes 8.32を単独で実行

[6.73GiB/s]（不安定）

GNU yes 8.32と、隣でwhile :; do :; doneを実行

[6.98GiB/s]（若干安定）

出力速度が不安定なときに、topで各CPUスレッドの負荷を眺めていると、ときどきプロセスが違うCPUスレッドに移動しているようにみえます。コアごとに動作周波数が違うせいか、yesのプロセスが別のコアに移ったとき、移動先のコアが省エネモードから最高周波数に立ち上がるまでのラグが影響しているんでしょうか？どうやって確かめましょうね？特定のスレッドに貼り付けたらエエんかしら？？

てなことを最初考えたんですが、実はそんなに難しい話ではなく、単にyesとpvが同じコアに割り付けられたときに、速度的に不利に働いているだけのような気がしてきました。実験するためtasksetを使って適当にスレッドを散らします。

隣のスレッド（= 同じコア）

$ taskset 0x2 yes | taskset 0x1 pv > /dev/null
[6.34GiB/s]

2つ隣のスレッド（= 違うコア、コアコンプレックス内）

$ taskset 0x4 yes | taskset 0x1 pv > /dev/null
[7.34GiB/s]

4つ隣のスレッド（= 違うコア、コアコンプレックス内）

$ taskset 0x10 yes | taskset 0x1 pv > /dev/null
[7.20GiB/s]

8つ隣のスレッド（= 違うコア、コアコンプレックス外）

$ taskset 0x100 yes | taskset 0x1 pv > /dev/null
[4.65GiB/s]

12つ隣のスレッド（= 違うコア、コアコンプレックス外）

$ taskset 0x1000 yes | taskset 0x1 pv > /dev/null
[4.66GiB/s]

かなり性能が変わります。コアが同じかどうか？はもちろん重要ですが、Zenアーキテクチャはコアコンプレックスの内か外かで性能に大きな違いが出ます。結果が安定しなかったのはプロセスがコアコンプレックス外に行ったり来たりしていたためでしょうね。

Debian TestingのLinux Kernel（現状、5.10.4-1）は、コアコンプレックスまでは考慮してくれないらしく、コアコンプレックス内と外のコアのどちらで実行しても良いよ、という設定にすると、処理が遅くなる方に割り付けてしまいます。

$ taskset 0x110 yes | taskset 0x1 pv > /dev/null
[4.59GiB/s]


$ top

top - 02:05:53 up 16 days,  9:39, 20 users,  load average: 0.64, 0.96, 1.06
Tasks: 355 total,   3 running, 349 sleeping,   2 stopped,   1 zombie
%Cpu0  :  7.5 us, 75.8 sy,  0.0 ni, 16.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st  ★pvはCPU 0で動作する
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  6.0 us, 79.1 sy,  0.0 ni, 14.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st  ★yesはCPU 4のほうが速いはずだが、CPU 8で動作する
%Cpu9  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :  0.7 us,  0.0 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu12 :  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu13 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu14 :  0.7 us,  0.3 sy,  0.0 ni, 99.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu15 :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  32106.7 total,    582.9 free,   3532.5 used,  27991.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used.  27906.8 avail Mem

パッと見、法則性が良くわかりませんでした。なるべくビジーなスレッドから遠い番号のCPUスレッドに割り当てようとする？のかもしれませんね。

（※1）Ryzen 7は1コア2スレッドなので、スレッド (0, 1), (2, 3), (4, 5) のように2スレッドが同じコアで実行されます。

メモ: 技術系？の話はFacebookから転記しておくことにした。後半を加筆。

ZephyrとQEMUのリセット その2 - 実装編

目次: Zephyr

Zephyrにはリブートを行う関数sys_reboot() が既に実装されており、アーキテクチャごとのリブート用関数sys_arch_reboot() を呼ぶ仕組みです。

// zephyr/subsys/power/reboot.c

void sys_reboot(int type)
{
	(void)irq_lock();
#ifdef CONFIG_SYS_CLOCK_EXISTS
	sys_clock_disable();
#endif

	sys_arch_reboot(type);    //★★アーキテクチャごとのリブート関数を呼ぶ

	/* should never get here */
	printk("Failed to reboot: spinning endlessly...\n");
	for (;;) {
		k_cpu_idle();
	}
}


// zephyr/soc/riscv/riscv-privilege/virt/soc.c

/* Reboot machine */
#define FINISHER_REBOOT		0x7777

void sys_arch_reboot(int type)
{
	volatile uint32_t *reg = (uint32_t *)SIFIVE_SYSCON_TEST;

	*reg = FINISHER_REBOOT;    //★★0x100000に0x00007777をWrite

	ARG_UNUSED(type);
}


// zephyr/soc/riscv/riscv-privilege/virt/soc.h

#include <soc_common.h>
#include <devicetree.h>

#define SIFIVE_SYSCON_TEST           0x00100000    //★追加
#define RISCV_MTIME_BASE             0x0200BFF8
#define RISCV_MTIMECMP_BASE          0x02004000

実装は素直にsys_arch_reboot() を追加しただけです。そんなに難しくないですよね。

動作確認

前回説明した通り、サンプルアプリのshellを使って動作確認します。

$ cmake -G Ninja -DBOARD=qemu_riscv32 ../samples/subsys/shell/shell_module/
$ ninja menuconfig
★★CONFIG_REBOOTとCONFIG_BOOT_BANNERを有効にする

$ ninja run

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv32
*** Booting Zephyr OS build v2.5.0-rc1-276-ge7d3bb714bc2  ***


uart:~$ kernel reboot cold
★★↑ここでリブートされる

*** Booting Zephyr OS build v2.5.0-rc1-276-ge7d3bb714bc2  ***


uart:~$ 

無事リブートしました。本当にリブートしてるのか不安になるくらい速いです。Zephyrは起動時に何も言わないので、Linuxと比べるとリブートは簡素に見えますね。速いのは良いんだけど、感動がちょっと薄いのが難点かも？

ZephyrとQEMUのリセット その1 - 準備編

目次: Zephyr

Zephyrでリセットできないんだけど、って言われて調べたので、忘れないうちに記録に残しておきます。

RISC-Vの規格ではリセット処理について何も記述されていませんので、リセット処理はハードウェア依存となります。QEMUのRISC-V virtマシンはどうかというと、SiFiveのナイスガイ達が作ってくれたリセットの仕組みがあります。

// qemu/hw/riscv/virt.c

static const struct MemmapEntry {
    hwaddr base;
    hwaddr size;
} virt_memmap[] = {
    [VIRT_DEBUG] =       {        0x0,         0x100 },
    [VIRT_MROM] =        {     0x1000,        0xf000 },
    [VIRT_TEST] =        {   0x100000,        0x1000 },    //★アドレス0x00100000にある★
    [VIRT_RTC] =         {   0x101000,        0x1000 },
...


// qemu/hw/riscv/virt.c

static void virt_machine_init(MachineState *machine)
{

...

    /* SiFive Test MMIO device */
    sifive_test_create(memmap[VIRT_TEST].base);    //★テストデバイスを追加している★


// qemu/hw/misc/sifive_test.c

/*
 * Create Test device.
 */
DeviceState *sifive_test_create(hwaddr addr)
{
    DeviceState *dev = qdev_new(TYPE_SIFIVE_TEST);
    sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
    sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
    return dev;
}

...

static void sifive_test_write(void *opaque, hwaddr addr,
           uint64_t val64, unsigned int size)
{
    if (addr == 0) {
        int status = val64 & 0xffff;
        int code = (val64 >> 16) & 0xffff;
        switch (status) {
        case FINISHER_FAIL:
            exit(code);
        case FINISHER_PASS:
            exit(0);
        case FINISHER_RESET:
            qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);    //★ここに到達するとリセットが掛かるはず★
            return;
        default:
            break;
        }
    }
    qemu_log_mask(LOG_GUEST_ERROR, "%s: write: addr=0x%x val=0x%016" PRIx64 "\n",
                  __func__, (int)addr, val64);
}


// qemu/include/hw/misc/sifive_test.h

enum {
    FINISHER_FAIL = 0x3333,
    FINISHER_PASS = 0x5555,
    FINISHER_RESET = 0x7777    //★この値を書けば良さそう★
};

つまり0x100000に0x00007777を4バイトWriteすれば良さそうです。

準備

Zephyrのサンプルshellを使います。理由はリブートするコマンドが簡単に使えるからです。CONFIG_REBOOTを有効にする必要があります。またshellは起動後プロンプトが出るだけで、リセットが掛かったかどうかわかりにくいため、起動時のバナーも有効にしておくと良いです。

CONFIG_REBOOT=y

  Boot Options  --->
    [ ] Reboot functionality

CONFIG_BOOT_BANNER=y

  General Kernel Options  --->
    Kernel Debugging and Metrics  --->
      [ ] Boot banner

ちょっと長いので一旦切ります。次回は実装と動作確認をします。

間違えたので消去。

そのZoomは最新ですか？

Zoomって、バージョンアップのお知らせを全くしてこないので、起動時に勝手にアップデートされていると思っていたんですが、全くそんなことはなかったですね。ずっと古いバージョンの5.3.1（2020/09/28リリース）のまま使っていました。

手動でアップデートしたところ、無事に最新版の5.4.9になりました。4ヶ月で大分数字が変わりましたね。

比較的新しいアプリの割にアップデートは保守的ですね？不思議な設計だな……？？

ミーティング後に表示される説

Facebookのコメントで「ミーティングの後」にバージョンアップのお知らせが出ることを教えてもらいました。

ミーティング前にバージョンアップすると遅刻する可能性大なので、ミーティング終了後に表示するのは良いアイデアですね。でも残念ながら、見たことないんだよな……。うちのZoomは何か変なんだろうか？？

メモ: 技術系？の話はFacebookから転記しておくことにした。加筆。

PlayStation Vita

久しぶりにPlayStation Vitaを起動したところ、ネットワークに繋げる系アプリがほぼ全滅していました。

プラットフォーム依存のゲーム機は、本体が元気でもサードパーティの撤退やサービス終了に伴って、勝手にポンコツになってしまい悲しいです。結構高かったのに……。

ソニー製

• flickr: 起動する、アカウント持ってないので動作不明
• foursquare: サービス終了
• LiveTweet: 起動する、PS Vitaの内蔵ブラウザがTwitter未サポート、アプリ認証できない
• near: サービス終了
• PlayStation Store: さすがにこれは動く
• radiko.jp: 動作する
• Reader: 起動する、機器認証でエラーになり進めなかった
• えちゃんねる: 起動する、Twitterのアプリ認証できない

サードパーティ製

• hulu: サービス終了
• NHKオンデマンド: サービス終了
• ニコニコ: サービス終了

PlayStation Storeを見ると「アプリケーション」はたった14個、サードパーティ製のアプリは1つ（ROBOTICS; NOTES ELITE AR）だけです。PS Vitaは既に9年経過（2011年12月発売）しており、ぶっちゃけソニーすらもVitaを見放している節があり、もう完全にオワコンです。

それなりに大きなプラットフォームの終焉を間近で見たのは貴重な体験、とはいえ、買った人は何も嬉しくないよね……。

メモ: 技術系？の話はFacebookから転記しておくことにした。多少修正。

苦境のANA

年末（2020年12月20日の日記参照）に、1月はSUPER VALUE 21 Jより安いチケットがVALUE 3で出ると予想しましたが、外れましたね。1/30の羽田→札幌便を見ると、最安はVALUE 3 Jで年末からほとんど変わっていません。

いやまあ、SUPER VALUE 21とVALUE 3の値段がほとんど変わらない時点で、かなり異常事態なんですけど……。

1/30の羽田→札幌便

なんと全25便中、半分近い11便が欠航しています。飛ばす回数を自体を減らし、客単価の維持とおそらく各便ごとの黒字を確保しているのでしょう。単発で黒字が出たとしても、確実に収益にはダメージがありますよね。安いイメージが付いてしまうより良いのかなあ？

燃料費などは減便で節約できても、飛行機はリースなので飛んでも飛ばなくてもお金が掛かります。飛ばせるならいくらでも飛ばしたいでしょう。

早いところCOVID-19には収束してもらって、気軽に旅行や帰省できる日が来てほしいですね。ANAは今かなり苦しいでしょうけど、日本の翼を担う会社として何とか踏みとどまってほしいところ……。