作成されたすべてのパイプで完全な64Kが使用されますか？

Question

パイプはどのように再バッファリングされていますか？私は多くのパイプを作成しているかもしれませんが、一度に数バイトしか送受信しないので、不必要にメモリを浪費したくありません。

編集：私はバッファリングが何であるか理解しています。バッファリングがLinuxパイプで具体的にどのように実装されているのか、つまりhighwatermarkに関係なく完全な64Kが割り当てられますか？

Answer 1

バッファは、プロデューサとコンシューマ間の速度の差を等しくするために使用されます。バッファを持たない場合は、生成されたバイトごとにタスクを切り替える必要があります。これは、コンテキスト切り替え、データやコードのキャッシュが決して熱くならないなどの理由で非常に非効率的です。消費者がプロデューサが消費するとすぐに、バッファの使用量は通常は少なくなりますが、読み込みには時間がかかります。プロデューサがコンシューマよりもはるかに高速であれば、バッファは完全にいっぱいになり、プロデューサはより多くのスペースが利用できるようになるまで待たされるでしょう。遅い生産者と高速消費者の逆の場合は、ほとんどの場合バッファのごく一部を使用します。

両方のプロセスが実際に並列に実行されているかどうか（たとえば別のコアで実行されているかどうか）、またはコアが共有されているかどうか、またOSのプロセス管理のためだけです。実際の同時実行性（別のコア/ CPU）を使用している場合、バッファは通常より少なく使用されます。

どのようにしても、アプリケーションのデータが多く生成されておらず、速度も同じであれば、ほとんどの場合、バッファーはほとんど完全には満たされません。しかし、OSレベルでは、完全な64 kBが割り当てられていれば驚くことはありません。しかし、エンベデッドデバイスを使用していない限り、64 kBはそれほど多くないので、最大サイズが常に割り当てられても、私はそれについて心配しません。

ところで、パイプバッファのサイズを変更するのは簡単ではありません。例えば、this discussionのようなものがありますが、実際にはバッファからのデータの使用方法を変更する回避策です。実際のバッファサイズ。あなたはulimit -pをチェックすることができますが、私はそれがあなたに必要なコントロールを与えることを100％確信していません。

EDIT：バッファは、そのサイズを変更行うようfs/pipe.cを見てみると、Linuxのコードでinclude/linux/pipe_fs_i.h、それが見えます。バッファの最小サイズはフルページですが、数バイトしか必要ない場合は無駄になります。私はこの時点ではわかりませんが、PIPE_DEF_BUFFERSを使用するコードでは64KBに4KBのページがあり、バッファが64KB未満になるかどうか疑問です（1ページの最小値は単なる追加の制限です）。