問題タブ [aio]

IO ジェネレーターのデバッグの一環として、x64 ハードウェア (複数のシステムで検証済み) で実行されている RH 6.4 で奇妙な結果セットに出くわしました。

-- アプリケーションは Linux 非同期 IO (つまり、非 posix) を使用して raw ディスク パーティション (/dev/sdb1、O_DIRECT) にアクセスし、root として実行されます。

-- アプリケーションは、100 io/s と 60% の書き込みを報告します。

-- アプリケーションの strace は、毎秒 100 の AIO 操作を反映して、io_submit() および io_getevents() への毎秒 100 の呼び出しを報告します。

-- 「dstat --aio」は 1 秒あたり 100 の操作を示します

-- iostat は予想どおり 40 回の読み取り/秒を報告しますが、予想の 2 倍の 120 回の書き込み/秒を報告します。

-- 同期 IO を使用する以前の実装では、「二重化された」書き込みは表示されません。

この動作は既知のバグですか?

バッファリングせずに、ユーザー空間との間でデータを転送せずに、あるファイル記述子から別のファイル記述子にデータを送信したいと考えています。そのような sendfile64() 関数は linux-aio で可能ですか?

いくつかの linux-aio の例 (C/C++) と単純なファイル コピー プログラムを調べました。これらの例はすべて、読み取り -> バッファ -> 書き込みを行います。

よろしく、フィリップ

現在、Netty サーバーをバージョン 4 (4.0.0.CR9) に移植しています。

これまでのところすべてが機能していますが、新しい java7 nio2 実装のパフォーマンス上の利点も試してみたいと思います。しかし、AioEventLoopGroup などの必要なクラスは、netty-all または netty バンドルでダウンロードされた他のパッケージ内にはないようです。

NIO2 サポートは Netty から削除されましたか?

カーネル AIO とO_DIRECT|O_SYNCを使用すると、カーネル バッファーへのコピーがなく、データが実際にディスクにフラッシュされたときにきめ細かい通知を受け取ることができます。ただし、 のユーザー空間バッファにデータを保持する必要がありますio_prep_pwrite()。

を使用splice()すると、データをコピーすることなく、カーネル スペース バッファ (パイプ) からディスクに直接移動できます。ただし、splice()データがキューに入れられるとすぐに戻り、ディスクへの実際の書き込みを待機しません。

目標は、データがフラッシュされたことを確認しながら、データをコピーせずにソケットからディスクに移動することです。以前の両方のアプローチを組み合わせる方法は?

と組み合わせるsplice()とO_SYNC、ブロックすることが期待splice()され、複数のスレッドを使用してレイテンシをマスクする必要があります。または、非同期io_prep_fsync()/を使用することもできますio_prep_fdsync()が、これは特定の書き込みではなく、すべてのデータがフラッシュされるのを待ちます。どちらも完璧ではありません。

必要なのは、splice()カーネル AIO との組み合わせであり、単一のイベント駆動型スレッドがデータをソケットからディスクに移動し、必要に応じて確認を取得できるように、ゼロ コピーと書き込みの非同期確認を可能にしますが、これはそうではないようです。サポートされています。良い回避策/代替アプローチはありますか?

AIOが機能していないように見えるファイルに簡単なことを書き込もうとしています。何が問題になる可能性がありますか? 不要な余分なヘッダーがあることはわかっています。

Linux 非同期 I/O システム コールを使用するライブラリを作成していますio_submitが、ext4 ファイル システムで関数のスケーリングが不十分な理由を知りたいです。可能であれば、io_submit大きな IO 要求サイズでブロックされないようにするにはどうすればよいですか? 私はすでに次のことを行っています（ここで説明されているように）：

• を使用しO_DIRECTます。
• IO バッファーを 512 バイト境界に合わせます。
• バッファー サイズをページ サイズの倍数に設定します。

カーネルが でどれくらいの時間を費やすかを観察するために、 と を使用しio_submitて 1 Gb のテスト ファイルを作成し、システム キャッシュ ( ) を繰り返しドロップして、ファイルのより大きな部分を読み取るというテストを実行しました。反復ごとに、読み取り要求が完了するまでにかかった時間と待機に費やされた時間を出力しました。カーネル バージョン 3.11 の Arch Linux を実行している x86-64 システムで、次の実験を実行しました。マシンには SSD と Core i7 CPU が搭載されています。最初のグラフは、読み取られたページ数と終了までの待機時間の関係を示しています。2 番目のグラフは、読み取り要求が完了するまでの待機に費やされた時間を表示します。時間は秒単位で測定されます。dd/dev/urandomsync; echo 1 > /proc/sys/vm/drop_cachesio_submitio_submit

比較のために、 を使用して同期 IO を使用する同様のテストを作成しましたpread。結果は次のとおりです。

非同期 IO は、約 20,000 ページの要求サイズまで期待どおりに機能しているようです。後はio_submitブロック。これらの観察は、次の疑問につながります。

• の実行時間がio_submit一定でないのはなぜですか?
• この不適切なスケーリング動作の原因は何ですか?
• ext4 ファイル システム上のすべての読み取り要求を、それぞれのサイズが 20,000 ページ未満の複数の要求に分割する必要がありますか?
• この「魔法の」値である 20,000 はどこから来たのでしょうか? 自分のプログラムを別の Linux システムで実行する場合、スケーリング動作が低下することなく、使用する最大 IO 要求サイズを決定するにはどうすればよいですか?

非同期 IO のテストに使用されるコードは次のとおりです。関連があると思われる場合は、他の情報源のリストを追加できますが、関連があると思われる詳細のみを投稿しようとしました.

ドライバーに AIO のサポートを追加し (カーネルランドでは .aio_read 、 .aio_write 呼び出し、ユーザーランドでは libaio )、さまざまなソースを調べましたが、 aio_read 、 .aio_write 呼び出しで iovector 引数へのポインターを格納するだけでよいかどうかを確認できます。 (このメモリは、たとえば aio_complete が呼び出されるまで手付かずのままであると仮定して)、または iovector データ構造をディープ コピーする必要があると仮定します。

例として \drivers\usb\gadget\inode.c の実装を見ると、ep_aio_rwtail 関数のポインターをコピーするだけのようです。

しかし、似たようなことをしようとすると、処理するまでにiovectorのデータが「破損」することが非常に定期的に発生します。

たとえば、ログに記録する aio_read/write 呼び出しで

しかし、カーネルスレッドで実際の作業を行うと（ユーザースペースmmにアタッチした後）、次のログが記録されました。

これは、ユーザー アプリケーションで 1 つの非同期コマンドのみを送信する非常に単純なテスト ケースです。

さらに興味深いことに、私は 3.13 カーネルで約 80% の確率で破損しています。

しかし、これまで 3.9 カーネルで見たことはありませんでした (ただし、3.13 にアップグレードする前に少しだけ使用しただけで、今では正気に戻り、何十回も試してみました)。( 3.9 カーネルで実行した例では、

これは鐘を鳴らしますか？

(もちろん、これらのアドレス/長さを自分で破損している可能性もありますが、3.9 でこれがなかったのは奇妙です)

編集: Linux aio の 3.13 コード (動作していた 3.9 から大幅に変更された) を確認した後、自分の質問に答えるには、fs\aio.c に次のように記述します。

static ssize_t aio_run_iocb(struct kiocb *req, unsigned opcode, char __user *buf, bool compat) { ... struct iovec inline_vec, *iovec = &inline_vec; ... ret = rw_op(req, iovec, nr_segs, req->ki_pos); ... }

したがって、この iovec 構造体はスタック上にあり、aio_read/write 関数が終了するとすぐに失われます。

また、ガジェット フレームワークには、\drivers\usb\gadget\inode.c... に (少なくとも 3.13 の) バグが含まれています。