☰

Linuxカーネルで現在のioリクエストを送信するプロセスを見つける

tag-icon • tag-icon linux-kernel io
Linuxカーネルで現在のioリクエストを送信するプロセスを見つける

私はLinuxカーネルを深く掘り下げました。 ioリクエストを追跡し、現在のioリクエストを送信したプロセスが正確に何であるかを知りたいですか？

カーネル文書によると、現在のプロセスを表すcurrentという構造があります。

しかし分析印刷block/blk-core.cの機能履歴書の提出これは現在のプロセスではないようです。

私のもの印刷これは：

printk(" Ata: in block/blk-core.c in submit_bio current task: %s pid:(%d): %s block %Lu on device %s (%u sectors)\n",
        current->comm, task_pid_nr(current),
            (rw & WRITE) ? "WRITE" : "READ",
            (unsigned long long)bio->bi_iter.bi_sector,
            bdevname(bio->bi_bdev, b),
            count);

しかし、出力は私が期待したものとは異なります。

[Thu Dec 31 15:18:49 2015]  Ata: in block/blk-core.c in submit_bio current task: jbd2/sda1-8 pid:(494): WRITE block 54798672 on device sda1 (8 sectors)

出力は現在のプロセスですジェバード2。 ~によるとこの回答 ジェバード2ファイルシステムが実行する機能です。それに比べて私のプロセスはDDPID：2479。

現在のioリクエストを送信したプロセスを正確に見つける方法は？それはまるでオートフしている

答え1

ディスクI / O要求は特定のプロセスを追跡できないことがよくあります。たとえば、両方のプロセスが同時に同じファイルにアクセスする場合（つまり、プロセス1の要求を処理する前にプロセス1が要求し、プロセス2が同じファイルをロードするように要求した場合）、アクセスを再追跡する必要があります。両方のプロセス。遅延書き込みの場合、存在しなくなったプロセスによって書き込みが発生する可能性があります。

iotopはプロセスごとのI / Oを表示します。文書ディスクレベルではなくレベルです。ファイルシステムドライバを見ると、current要求されたプロセスが指定されます。ただし、ブロックデバイスドライバを見ている場合、プロセスがファイルシステムをバイパスしてディスクに直接アクセスしない限り、I / O要求は内部サブシステムから発生します。だからこそiotopのプロセス固有の統計が合計と一致しません。：合計はディスクレベルのものです。

上記のように、通常、要求を引き起こしたプロセスまでディスクI / O要求を追跡することは不可能です。可能であれば、この種のトレースを可能にするデバッグモードがあるかどうかはわかりません。非常にリソース集約的であると予想されます。

関連情報