cat filepath > /dev/null安価なメモリキャッシュメカニズムとして使用したいと思います。私が疑問に思っているのは、もう一度呼び出すと、ファイルがすでにディスクキャッシュにある場合、OSは何もしないほどスマートですか？
更新：これをCIFSボリュームでテストし、fadvise POSIX_FADV_WILLNEEDを使用してファイルをローカルにキャッシュしました（コマンドラインでlinux-ftoolsを使用）。これを機能させるには、ボリュームを読み取り/書き込みモードでマウントする必要があることがわかりました。読み取り専用モードでは、fadviseは無視されているようです。これは、sambaoplockメカニズムと関係があるはずです。
いいえ、できません。
プログラムが何もしないかどうかを判断することは、通常、単に実行するよりも複雑です。
とにかくメモリキャッシュを制御する必要があるのはなぜですか？どうしても必要な場合は、tmpfsファイルシステムまたはcompcache（圧縮RAMブロックデバイス）の使用を検討してください。
ファイルを/dev/ nullにキャットするよりもposix_fadvise（...、POSIX_FADV_WILLNEED）を使用する方が適切です。実際のIOが少なくて済み、ファイルの内容をユーザースペースRAMに読み込んで、CPUキャッシュを破壊する必要がありません。
さらに、ファイルの関連部分がすでにキャッシュにある場合、posix_fadviseはおそらくcatファイル> / dev/nullよりもはるかに少ない作業を実行します
ページを今すぐコアにする必要があると思われる場合は、ファイルの関連セクションをmmapしてロックします（後でロックを解除します。メモリの負荷が高い場合はすぐに破棄される可能性があります）。これにはroot権限が必要です。
一般に、この種のことを行うことは悲観的であり、しかし避けるべきです。カーネルを希望どおりに動作させると、実際のワークロードを最適化する能力が低下する可能性があります。
他の答えが言っているように、それは何もしません。しかし、あなたが本当に意味したのは：
もう一度呼び出すと、ファイルがすでにディスクキャッシュにある場合、OSはディスクから2回目に読み取らないほど賢いですか？
...答えはyes1です。結局のところ、これがディスクキャッシュの仕組みです。
1.とにかく、問題のファイルシステムがページキャッシュを使用している限り。
それは地獄のように速いでしょう、しかしそれはノーオペレーションではありません（もしそうなら、syscallsが彼らの約束された機能の代わりに予期しないことをする正当な理由があるでしょう...）。ただし、使用するファイルシステムドライバとカーネルオプションによっては、メモリ帯域幅の近くで実行されている可能性があります。