Linux におけるゼロコピー技術の使用に関する簡単な分析

この記事では、Linux におけるいくつかの主要なゼロコピーテクノロジと、ゼロコピーテクノロジを適用できるシナリオについて説明します。ゼロコピーの概念をすぐに理解するために、一般的なシナリオを紹介しましょう。

引用

サーバープログラム（Webサーバーやファイルサーバー）を作成する場合、ファイルのダウンロードは基本的な機能です。このとき、サーバーのタスクは、接続されたソケットからサーバーホストディスク上のファイルを変更せずに送信することです。通常、これを完了するには次のコードを使用します。

while((n = read(diskfd, buf, BUF_SIZE)) > 0)
  書き込み(sockfd, buf, n);

基本的な操作は、ディスクからファイルの内容をバッファに周期的に読み取り、バッファの内容をソケットに送信することです。ただし、Linux の I/O 操作はデフォルトでバッファリングされた I/O です。ここで主に使用される 2 つのシステムコールは read と write ですが、オペレーティングシステムがその中で何を行うかはわかりません。実際、上記の I/O 操作では複数のデータコピーが発生します。

アプリケーションがデータにアクセスすると、オペレーティングシステムはまず、そのファイルが最近アクセスされたかどうか、またそのファイルの内容がカーネルバッファにキャッシュされているかどうかを確認します。キャッシュされている場合、オペレーティングシステムは、read システムコールによって提供された buf アドレスに基づいて、カーネルバッファの内容を buf で指定されたユーザー空間バッファに直接コピーします。そうでない場合、オペレーティングシステムはまずディスク上のデータをカーネルバッファーにコピーします。カーネルバッファーは現在、主に DMA を使用して転送を行っています。次に、カーネルバッファーの内容をユーザーバッファーにコピーします。

次に、書き込みシステムコールは、ユーザーバッファーの内容をネットワークスタックに関連付けられたカーネルバッファーにコピーし、最後にソケットはカーネルバッファーの内容をネットワークカードに送信します。

ここまで述べてきましたが、写真をよく見た方が良いでしょう。

データコピー

上図からわかるように、合計 4 つのデータコピーが生成されます。ハードウェアとの通信に DMA を使用した場合でも、CPU は 2 つのデータコピーを処理する必要があります。同時に、ユーザーモードとカーネルモードの間で複数のコンテキストスイッチが発生するため、CPU の負荷が確実に増加します。
このプロセスでは、ファイルの内容に変更を加えなかったため、カーネル空間とユーザー空間の間でデータをコピーすることは間違いなく無駄であり、ゼロコピーは主にこの非効率性を解決するためのものです。

ゼロコピーテクノロジーとは何ですか? ##

ゼロコピーの主なタスクは、CPU が 1 つのストレージユニットから別のストレージユニットにデータをコピーするのを防ぐことです。主にさまざまなゼロコピーテクノロジを使用して、CPU が大量のデータコピータスクを実行するのを回避し、不要なコピーを減らしたり、他のコンポーネントにこの種の単純なデータ転送タスクを実行させたりすることで、CPU が他のタスクに集中できるようにします。これにより、システムリソースをより効率的に使用できるようになります。

前回の記事の例に戻りましょう。データのコピー回数を減らすにはどうすればよいでしょうか?明らかな焦点は、カーネル空間とユーザー空間の間でのデータのやり取りを減らすことであり、これにより、ゼロコピーのタイプも導入されます。

ユーザー空間を通過せずにデータ転送を許可する

mmap の使用#####

コピー数を減らす 1 つの方法は、読み取りではなく mmap() を呼び出すことです。

buf = mmap(diskfd, len);
書き込み(sockfd、buf、len);

アプリケーションが mmap() を呼び出すと、ディスク上のデータが DMA 経由でカーネルバッファにコピーされます。その後、オペレーティングシステムはこのカーネルバッファをアプリケーションと共有するため、カーネルバッファの内容をユーザースペースにコピーする必要はありません。アプリケーションは再度 write() を呼び出し、オペレーティングシステムはカーネルバッファーの内容をソケットバッファーに直接コピーします。この処理はすべてカーネル状態で行われます。最後に、ソケットバッファーはデータをネットワークカードに送信します。
同様に、画像も簡単に確認できます。

mmap

read の代わりに mmap を使用すると、明らかに 1 回のコピーが削減され、コピーされるデータの量が多い場合の効率が確実に向上します。しかし、mmap を使用するにはコストがかかります。 mmap を使用すると、隠れた落とし穴に遭遇する可能性があります。たとえば、プログラムがファイルをマップしたが、そのファイルが別のプロセスによって切り捨てられた場合、不正なアドレスにアクセスしたため、書き込みシステムコールは SIGBUS シグナルによって終了します。デフォルトでは、SIGBUS シグナルはプロセスを強制終了し、コアダンプを生成します。サーバーがこのように終了すると、損失が発生します。

この問題を回避するために、通常は次の解決策を使用します。

SIGBUS シグナル用のシグナルハンドラーを作成する SIGBUS シグナルが発生すると、シグナルハンドラーは単に戻り、write システムコールは中断される前に書き込まれたバイト数を返し、errno は success に設定されますが、これは問題の核心を解決していないため、対処方法としては適切ではありません。

ファイルリースロックの使用通常、この方法はファイル記述子のリースロックを使用するために使用します。カーネルからファイルのリースロックを申請します。他のプロセスがファイルを切り捨てる場合、カーネルはリアルタイムの RT_SIGNAL_LEASE シグナルを送信し、カーネルがファイルに対する読み取り/書き込みロックを破棄していることを通知します。この方法では、プログラムが不正なメモリにアクセスして SIGBUS によって強制終了される前に、書き込みシステムコールが中断されます。 write は書き込まれたバイト数を返し、errno を success に設定します。
mmap の前にファイルをロックし、操作後にロックを解除する必要があります。

if(fcntl(diskfd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
  perror("カーネルリースセットシグナル");
  -1 を返します。
}
/* l_type は F_RDLCK F_WRLCK ロックにすることができます*/
/* l_type は F_UNLCK ロック解除にすることができます*/
if(fcntl(diskfd, F_SETLEASE, l_type)){
  perror("カーネルリースセットタイプ");
  -1 を返します。
}

sendfile の使用#####

カーネルバージョン 2.1 以降、Linux では操作を簡素化するために sendfile が導入されました。

#include <sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *オフセット, size_t カウント);

sendfile() システムコールは、入力ファイル記述子 in_fd と出力ファイル記述子 out_fd の間でファイルの内容 (バイト) を転送します。記述子 out_fd はソケットを参照する必要があり、in_fd が指すファイルは mmap 可能である必要があります。これらの制限により、sendfile の使用は、ファイルからソケットへのデータ転送のみ可能となり、その逆は不可能となります。
sendfile を使用すると、データのコピー数が減るだけでなく、コンテキストの切り替えも減り、データ転送は常にカーネル空間でのみ行われるようになります。

sendfile システムコールプロセス

sendfile を呼び出したときに別のプロセスがファイルを切り捨てるとどうなりますか?シグナルハンドラを設定しないと仮定すると、sendfile 呼び出しは単に中断される前に転送されたバイト数を返すだけであり、errno は成功に設定されます。 sendfile を呼び出す前にファイルをロックすると、sendfile は以前と同じように動作し、RT_SIGNAL_LEASE シグナルを受信します。

これまで、データのコピー数は削減されましたが、ページキャッシュからソケットキャッシュへのコピーがまだ 1 つ残っています。では、このコピーも省略できますか?

ハードウェアの助けがあれば、それが実現できます。これまでは、ページキャッシュ内のデータをソケットキャッシュにコピーしていました。実際には、バッファー記述子をソケットバッファーに渡し、データ長を渡すだけで済みます。このようにして、DMA コントローラーはページキャッシュ内のデータを直接パッケージ化し、ネットワークに送信できます。

要約すると、sendfile システムコールは DMA エンジンを使用してファイルの内容をカーネルバッファーにコピーし、ファイルの場所と長さの情報を含むバッファー記述子をソケットバッファーに追加します。この手順では、カーネル内のデータはソケットバッファーにコピーされません。DMA エンジンは、カーネルバッファー内のデータをプロトコルエンジンにコピーし、最後のコピーを回避します。

DMA によるファイル送信

ただし、この収集およびコピー機能には、ハードウェアとドライバーのサポートが必要です。

スプライスの使用#####

sendfile はファイルからソケットへのデータのコピーにのみ適用可能であり、使用範囲が制限されます。 Linux では、バージョン 2.6.17 で 2 つのファイル記述子間でデータを移動するための splice システムコールが導入されました。

#define _GNU_SOURCE /* feature_test_macros(7) を参照 */
#include <fcntl.h>
ssize_t splice(int fd_in, loff_t *off_in, int fd_out, loff_t *off_out, size_t len, unsigned int flags);

スプライス呼び出しは、カーネル空間とユーザー空間間でデータをコピーせずに、2 つのファイル記述子間でデータを移動します。これは、len の長さのデータを fd_in から fd_out にコピーしますが、2 つのうちの 1 つはパイプデバイスである必要があり、これは現時点での splice の制限の一部でもあります。 flags パラメータには次の値があります。

SPLICE_F_MOVE : データをコピーするのではなく移動しようとします。これはカーネルへの小さなヒントです。カーネルがパイプからデータを移動できない場合、またはパイプのバッファが完全なページでない場合は、データをコピーする必要があります。初期の Linux 実装にはいくつか問題があるため、このオプションは 2.6.21 以降では機能しませんが、それ以降の Linux バージョンでは実装される予定です。
** SPLICE_F_NONBLOCK** : スプライス操作はブロックされません。ただし、ファイル記述子が非ブロッキング I/O 用に設定されていない場合は、splice の呼び出しがブロックされる可能性があります。
** SPLICE_F_MORE**: 後続のスプライス呼び出しでは、より多くのデータが含まれます。

スプライス呼び出しは Linux によって提案されたパイプバッファメカニズムを利用するため、少なくとも 1 つの記述子はパイプである必要があります。

上記のゼロコピー技術はすべて、ユーザー空間とカーネル空間間のデータのコピーを減らすことによって実装されています。ただし、ユーザー空間とカーネル空間間でデータをコピーしなければならない場合もあります。現時点では、ユーザー空間とカーネル空間の間でデータをコピーするタイミングにのみ焦点を当てることができます。 Linux は通常、システムのオーバーヘッドを削減するためにコピーオンライトを使用しており、このテクノロジは COW と呼ばれることがよくあります。

スペースの制約により、この記事ではコピーオンライトについて詳しく説明しません。大まかに言うと、複数のプログラムが同時に同じデータにアクセスする場合、各プログラムにはこのデータへのポインタがあります。各プログラムの観点から見ると、このデータは独立して所有されています。プログラムがデータの内容を変更する必要がある場合にのみ、データの内容がプログラム独自のアプリケーション空間にコピーされます。この時点で、データはプログラムのプライベートデータになります。プログラムがデータを変更する必要がない場合は、データを独自のアプリケーションスペースにコピーする必要はありません。これにより、データのコピーが削減されます。コピーオンライトの内容については、別の記事で説明できるほどです。。。

さらに、ゼロコピー技術もいくつかあります。たとえば、従来の Linux I/O に O_DIRECT マークを追加すると、直接 I/O を実行し、自動キャッシュを回避できます。また、未熟な fbufs 技術もあります。この記事では、すべてのゼロコピー技術を網羅しているわけではなく、一般的な技術をいくつか紹介するだけです。興味があれば、自分で勉強してください。一般的に、成熟したサーバープロジェクトでは、データ転送速度を向上させるために、カーネルの I/O 関連部分も独自に変更します。

Linux でのゼロコピー技術の使用に関するこの記事はこれで終わりです。Linux のゼロコピーに関する関連コンテンツをさらにご覧になりたい場合は、123WORDPRESS.COM で過去の記事を検索するか、以下の関連記事を引き続きご覧ください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: