2
Linux / BSDに汎用のバッチ処理システムコールがないのはなぜですか？
バックグラウンド： システムコールのオーバーヘッドは、主にユーザー空間からカーネル空間へ、およびその逆へのコンテキストの切り替えにより、関数呼び出しのオーバーヘッドよりもはるかに大きくなります（推定範囲は20〜100倍）。関数呼び出しのオーバーヘッドを節約するためにインライン関数が一般的であり、関数呼び出しはsyscallsよりもはるかに安価です。開発者が1つのsyscallでカーネル内の操作を可能な限り処理することにより、システムコールのオーバーヘッドの一部を避けたいと考えるのは理にかなっています。 問題： これは、のような（？余計な）システムコールをたくさん作成したsendmmsgを（） 、recvmmsg（）などのようにchdir、オープン、のlseekおよび/またはシンボリックリンクの組み合わせ：openat、mkdirat、mknodat、fchownat、futimesat、newfstatat、unlinkat、fchdir、ftruncate、fchmod、renameat、linkat、symlinkat、readlinkat、fchmodat、faccessat、lsetxattr、fsetxattr、execveat、lgetxattr、llistxattr、lremovexattr、fremovexattr、flistxattr、fgetxattr、pread、pwrite等... 現在copy_file_range()、読み取りlseekと書き込みsyscallを組み合わせたLinuxが追加されました。これがfcopy_file_range（）、lcopy_file_range（）、copy_file_rangeat（）、fcopy_file_rangeat（）およびlcopy_file_rangeat（）になるまでの時間の問題です...しかし、X個の呼び出しの代わりに2個のファイルがあるため、X ^ 2になる可能性がありますもっと。わかりました、LinusとさまざまなBSD開発者はそこまで行きませんが、私のポイントは、バッチシステムコールがあれば、これらのすべて（ほとんど？） libc側にオーバーヘッドがある場合。 システムコールをバッチ処理するための非ブロッキングシステムコール用の特別なシステムコールスレッドを含む、多くの複雑なソリューションが提案されています。ただし、これらの方法は、libxcbとlibX11の場合とほぼ同じ方法で、カーネルとユーザー空間の両方にかなりの複雑さを追加します（非同期呼び出しにはより多くのセットアップが必要です） 解決？： 汎用バッチ処理システムコール。これにより、特殊なカーネルスレッドを使用することに伴う複雑さなしに、最大コスト（複数モードスイッチ）が軽減されます（ただし、その機能は後で追加できます）。 socketcall（）syscallには、基本的にプロトタイプの基本がすでにあります。引数の配列を取ることからそれを拡張して、代わりに戻り値の配列、引数の配列へのポインター（syscall番号を含む）、syscallの数、およびflags引数などを取得します。 batch(void *returns, void *args, long ncalls, long flags); 大きな違いの1つは、前のsyscallsの結果を後続のsyscalls（たとえば/ で使用するためのファイル記述子）で使用できるように、引数はおそらくすべて単純化のためのポインターである必要があることです。open()read()write() 考えられるいくつかの利点： ユーザースペースの削減->カーネルスペース->ユーザースペースの切り替え 可能なコンパイラスイッチ-fcombine-syscallsは、自動的にバッチ処理を試行します 非同期操作のオプションフラグ（fdを返すとすぐに監視されます） ユーザースペースに将来の結合されたsyscall関数を実装する機能 質問： バッチ処理システムコールを実装することは可能ですか？ 明らかな落とし穴がありませんか？ メリットを過大評価していますか？ バッチ処理システムコールの実装を気にすることは価値がありますか（Intel、Google、またはRedhatで働いていません）。 以前に自分のカーネルにパッチを適用しましたが、LKMLを扱うのは恐ろしいです。 歴史は、「普通の」ユーザー（git書き込みアクセスのない非企業のエンドユーザー）にとって何かが広く有用であっても、上流（unionfs、aufs、cryptodev、tuxoniceなど）に受け入れられることはないことを示しています。 参照： FlexSC：例外のないシステムコールを使用した柔軟なシステムコールスケジューリング 専用ユーザーおよびカーネルCPUを介したシステムコールのオーバーヘッドの回避