NUMAアーキテクチャのスループット性能について（その２）


[NUMAアーキテクチャのスループット性能について](https://qiita.com/MahoTakara/items/9fa7e29c1faa74e4e77c)の続きで、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コアの若い順から割り当てると言った状態ではないですね。

![スクリーンショット 2017-12-28 19.54.03.png](https://qiita-image-store.s3.amazonaws.com/0/42829/e22a8403-d622-4261-b87c-f4df0fbaaea0.png "スクリーンショット 2017-12-28 19.54.03.png")



## ケース８ ノードバインド 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に割当たっていないことが、このスクリーンショットから察することができます。

![スクリーンショット 2017-12-28 20.03.19.png](https://qiita-image-store.s3.amazonaws.com/0/42829/b4285b7b-56b8-1b2c-4746-50f3c2dc034f.png "スクリーンショット 2017-12-28 20.03.19.png")



## ケース９ 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系のためにあると言っても間違いでは無い様です。

![スクリーンショット 2017-12-28 20.08.11.png](https://qiita-image-store.s3.amazonaws.com/0/42829/d2fd65c4-aaf0-e95c-a415-bfe3e99646b7.png "スクリーンショット 2017-12-28 20.08.11.png")


# まとめ

カーネル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が必須であることが明らかになったと思います。