UCXを試す(4)
引き続き、 uct_hello_world.c
をC++に写経しながら、次はインターフェースのopen(uct_iface_open
)と、属性取得(uct_iface_attr_t
)をしてみます。
https://gist.github.com/keisukefukuda/63cdd3516bec21437be973b845b2d476
(前回と同じ部分を省略) Using rc/mlx4_0:1 iface_config of rc/mlx4_0:1 device_addr_len = 3 iface_attr_len = 1 ep_addr_len = 4 max_conn_priv = 0 overhead = 7.5e-08 latency = 1e-09 * x + 7e-07 priority = 10
インターフェースごとに、いくつかの属性値が取れるようです。
UCXを試すメモ(3)
uct_md_query()
関数を使って、Memory DomainのAttributesを取ってみました。
https://gist.github.com/keisukefukuda/cf55bf8aaf9f343f529c25ff46487ce0
Resources: self component name: self max alloc: 0 (0[GiB]) max reg: 18446744073709551615 (17179869184[GiB]) rkey packed size: 8 Devices: self/self tcp component name: tcp max alloc: 0 (0[GiB]) max reg: 0 (0[GiB]) rkey packed size: 8 Devices: ib0/tcp eth0/tcp eth1/tcp ib/mlx4_0 component name: ib max alloc: 18446744073709551615 (17179869184[GiB]) max reg: 18446744073709551615 (17179869184[GiB]) rkey packed size: 16 Devices: mlx4_0:1/rc mlx4_0:1/ud cuda_cpy component name: cuda_cpy max alloc: 0 (0[GiB]) max reg: 18446744073709551615 (17179869184[GiB]) rkey packed size: 8 Devices: cudacopy0/cuda_copy sysv component name: sysv max alloc: 18446744073709551615 (17179869184[GiB]) max reg: 0 (0[GiB]) rkey packed size: 32 Devices: sysv/mm posix component name: posix max alloc: 18446744073709551615 (17179869184[GiB]) max reg: 0 (0[GiB]) rkey packed size: 37 Devices: posix/mm cma component name: cma max alloc: 0 (0[GiB]) max reg: 18446744073709551615 (17179869184[GiB]) rkey packed size: 8 Devices: cma/cma Using rc/mlx4_0:1
max_alloc
とか、 max_reg
の2つは今のところ意味のある値は出ていないっぽいですね(なお、18446744073709551615
というのはUINT64_MAX
です)。
rkey packed size
というのは、まだ意味がよくわかりません。
上で出力していない値に、
* uct_linear_growth_t reg_cost
* cpu_set_t local_cpus
というフィールドが2つあります。これもちょっとおもしろそうではありますが、正しい値が出るかどうかは次回のお楽しみ。
reg_cost
というのは、メモリ領域のRegistrationにかかるコストだと思われます。高速通信、特にRDMAを実現するためには、メモリ領域がディスクにスワップされては困りますし、ネットワークデバイスがメモリに直接書き込む際に物理アドレスを知っている必要があります。そこで、LinuxではPage Locked Memory(CUDAでいうPinned Memory)という機能を使って、特定のメモリ領域がSwap Outされないようにするわけですね。その操作をRegistrationと呼びます。
次に、local_cpus
というのは、デバイスとCPUのトポロジのことを言っていると思われます。ネットワークデバイスから見てどのCPU(あるいはNUMAノード)が一番近いかというのは重要で、下手をするとQPIなどを通って通信するハメになるので、どのCPU(正確にはメモリ)を送信/受信バッファにするかというのは慎重に決める必要があります。この情報は hwloc
などのライブラリを使っても知ることが出来ますが、UCXでどの程度の情報を返してくれるのかは興味があります。
UCXを試すメモ(2)
test/examples/uct_hello_world.c
を参考にして、まずは Memory Domain, Device, Transport Layer の一覧を取得するコードを書いてみます。
https://gist.github.com/keisukefukuda/bfa28464b10d36ae2321b22db73f7b38
通信のためのデバイス/ハードウェアは、上記の3つの階層によって抽象化されています。Memory domain(MD)は、Memoryと名前はついていますが、通信のためのハードウェアリソースを抽象化したもの。ちょっとイマイチ具体的なイメージがわかない。TransportLayer(TL)は、MDの中でサポートされている通信モデル(?)を表し、それにDeviceもセットで付いてきます。基本的には、TLはデバイス依存です。Infinibandの場合はRC
とUD
に対応するrc
とud
が出力されています。
とりあえず、このコードでは、一覧取得までを書き、次に uct_md_attr
を使った属性の取得は次回。
コンパイル&実行例(IBが接続されているマシン上で実行):
$ g++ -std=c++11 -g -o ucx_dev_query ucx_dev_query.cpp -Wall -Wextra -Werror -I${UCX}/install/include -L${UCX}/install/lib -pedantic -lucs -luct -Wl,-rpath,${UCX}/install/lib $ ./ucx_dev_query mlx4_0:1 rc Resources: self self/self tcp ib0/tcp eth0/tcp eth1/tcp ib/mlx4_0 mlx4_0:1/rc mlx4_0:1/ud cuda_cpy cudacopy0/cuda_copy sysv sysv/mm posix posix/mm cma cma/cma Using rc/mlx4_0:1