NUMAアーキテクチャのスループット性能についての続きで、RFSを利用してもしなくてもスループットが改善しなかったので、Linux Kernel 2.6系 と 3系で挙動が違いのではないかと推定されたので、検証してみました。 結果として、RFSは2.6系では有効ですが、3系では使わなくても性能が出せることが判りました。
OSのバージョン
カーネル 2.6系は、以下のCentOS 6.9 を利用しました。
Linux and Processor Details
Linux: Linux version 2.6.32-696.16.1.el6.x86_64 (mockbuild@c1bl.rdu2.centos.o
Build: (gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC) )
Release : 2.6.32-696.16.1.el6.x86_64
Version : #1 SMP Wed Nov 15 16:51:15 UTC 2017
cpuinfo: model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
cpuinfo: vendor_id : GenuineIntel
cpuinfo: microcode : 184549409
cpuinfo: cpuid level : 20
# of CPUs: 32
Machine : x86_64
Nodename : test61.takara.org
ケース７ ノーマル CentOS 6.9
OSをインストールしただけの状態のスループットを測ります。 コマンドでアプリを起動するだけです。
$ ./start.sh
結果は、Linux カーネル 3系よりだいぶ低めでした。
経過時間(秒) Hit スループット(Hit/sec)
5.00471496582 284 56.7464884493
10.0097818375 396 79.1198220035
15.0148329735 353 70.5287499382
20.0198588371 333 66.5331227194
25.0249118805 365 72.9263000487
30.0299630165 379 75.7235020583
35.0350120068 396 79.1201046726
40.0400519371 467 93.3059489034
CPU時間としては、やはり、Node#0のコアに集中していることが判ります。 Node#1 への少しは割り振っているけど、3系の様に、CPUコアの若い順から割り当てると言った状態ではないですね。
ケース８ ノードバインド CentOS 6.9
プロセスを担当するCPUのノード側のメモリを利用する、最も性能が期待できる設定で試します。
$ numactl --localalloc ./start.sh
同じハードウェア条件ですが、カーネル 2.6系では、だいぶ性能が落ちる様です。
経過時間(秒) Hit スループット(Hit/sec)
5.00502586365 346 69.1305118947
10.010133028 425 84.9132667976
15.0151848793 413 82.5166276539
20.0202338696 450 89.9092098552
25.0252799988 512 102.296759466
30.0303139687 409 81.7177270847
35.0353620052 494 98.7003514032
40.0404059887 442 88.3109122439
45.0454549789 458 91.5075958082
ケース７の時と同じ様に、Node#1 のCPUに割当たっていないことが、このスクリーンショットから察することができます。
ケース９ RFS (Receive Flow Steering) とノードバインドを併用
2.6系で実装されたRFSの効果を測ってみます。 RFS設定は、前回と同じで、GitHub https://github.com/takara9/baremetal_rfs_tune のシェルを利用します。
# ethtool -K eth0 ntuple on
# ./set_rfs.sh
RFS設定後に、アプリケーションを立ち上げて、測定に入っていきます。
$ numactl --localalloc ./start.sh
結果は、最初の立ち上がりは良くないですが、カーネル 2.6系で最高のスループットを記録しています。
経過時間(秒) Hit スループット(Hit/sec)
5.00498914719 273 54.5455728218
10.0100200176 321 64.1354685535
15.0149941444 325 64.9354006165
20.0200049877 470 93.90589046
25.0249831676 501 100.100336503
30.0300121307 593 118.480832853
35.0349850655 590 117.882755351
40.0400221348 555 110.8882896
スクリーンショットからは、RFSの機能によって、ほぼ均等にCPUコアへ要求が割り振られていることが判ります。 RFSはカーネル2.6系のためにあると言っても間違いでは無い様です。
まとめ
カーネル3系と今回のカーネル2.6系のケースで、一つの表にまとめてみます。 3系のカーネルでは、RFSによる顕著な性能改善が見られませんでしたが、2.6系では明らかな改善が見られます。
| ケース | 3系スループット | 2.6系スループット |
|---|---|---|
| ケース 1,7 ノーマル | 104.494 | 75.723 |
| ケース 4,8 プロセスを担当するCPUのノード側のメモリを利用 | 114.077 | 81.717 |
| ケース 6,9 RFSとノードバインドを併用 | 114.083 | 118.480 |
この事から、3系カーネルではRFSは不要であり、2.6系カーネルはRFSが必須であることが明らかになったと思います。