1

私は Linux カーネルのシステム コールを作成するように割り当てられました。これは奇妙なことに、ユーザーの 1 分あたりの最大転送量 (ファイル操作の場合) を決定 (および削減) します。このシステム コールが呼び出されlim_fs_usage、すべてのユーザーが 1 分間にアクセスできる最大バイト数のパラメーターを受け取ります。簡単に言うと、Linux でのすべてのファイル システム操作の帯域幅を決定します。このプロジェクトでは、この制限されたリソース (ファイル アクセス) をユーザー間で配布するための適切な方法を選択することも求められますが、これは大きな問題にはならないと思います。

長い長い検索とスキャンを行いましたが、ファイル システムへのアクセスをプログラムで管理する方法を見つけることができませんでした。( )ハード ドライブをメモリにマッピングmmap()し、メモリ操作を管理することを考えましたが、これは無駄になりました。また、仮想ファイル システムを監視および制限するために、仮想ファイル システムの API を見つけようとしましたが、見つかりませんでした。アイデアをお願いします...どんな助けも大歓迎です。前もって感謝します...

4

3 に答える 3

1

IOスケジューラの実装としてこれを行うことができるのだろうか.

Linux で IO 帯域幅の制限を行う際の主な問題は、デバイスの近くに到達するまでに、カーネルが原因を忘れてしまっていることです。

同様に、IO の特定の部分の責任者を特定する際に、非常にトリッキーな状況に陥ることがあります。

  • バイナリがデマンド ロードされている場合、それを行う IO の所有者は誰ですか?
  • メモリのマップされたセクション (デマンド ロードの実行可能ファイルなど) は、他の誰かがRAM を使いすぎたためにメモリから追い出される可能性があり、その結果、カーネルはそれらのページを削除することを選択し、他のユーザーのクォータに不当な負担がかかります。次にページインします
  • IO操作は組み合わせることができ、異なるユーザーからのものかもしれません
  • 書き込み操作は、カーネルがそれをスケジュールする方法に応じて、遅かれ早かれ IO を引き起こす可能性があります。後のスケジュールは、その間に同じブロックに対して別の書き込みが行われるため、長期的に実行する必要がある IO が少なくなることを意味する場合があります。キャッシュ内のすでにダーティなブロックに書き込みを行っても、それ以上ダーティになることはありません。

これらすべての注意事項を理解し、それでも理解したい場合は、IOスケジューラとしてそれを行うことが道だと思います。

IO スケジューラは Linux (2.6) ではプラグ可能であり、動的に変更できます。カーネルは、デバイス上のすべての IO (IO スケジューラはブロック デバイスごとに切り替え可能) が終了するのを待ってから、新しいものに切り替えます。

于 2009-12-20T22:40:44.683 に答える
0

長い間考えて探した結果、提案された「フッキング」方式を採用することにしました。hdd_bandwith_limitのようなグローバル変数を初期化して管理する新しいシステムコールを作成することを考えています。この変数は、（「count」変数の代わりに）システムコールの変更された実装Read()で使用されます。Write()次に、このリソースの配布を決定します。これが実際の問題です。おそらく、特定の瞬間にシステムを使用しているユーザーの数を調べ、このリソースを均等に分割します。ラウンドロビンのようなディストリビューションになります。しかし、それでも、私はこの配布の問題についての提案を受け入れています。SJF、FCFS、またはラウンドロビンになりますか？同期は別の問題です。ユーザーの仕事が短いか長いかをどうやって知ることができますか？それとも彼が手術を終えたかどうか？

于 2009-12-21T13:56:36.157 に答える
0

緊急なので、実現可能性について調査はせずに、頭の中で思いついたアイデアをお伝えします。ファイル システム アクセスを処理するシステム コールを監視するためのフックを挿入するのはどうでしょうか。さまざまなファイルシステム (ext3、ext4 など) を処理するために特殊なカーネル モジュールを作成することになるかもしれませんが、概念実証として、1 つから始めることができます。root が自分の操作のためにメモリ、プロセス空間、およびディスクにブロックを予約していることを忘れないでください。

メモリ操作の管理は、あなたがやろうとしていることとは関係ないように思えます (しかし、おそらく私はここで間違っています)。

于 2009-12-20T16:48:17.803 に答える