プロセスのメモリ使用量情報を取得する必要があります。私はそれがあるかもしれないことを知っていますが、/proc/${pid}/statmそれを得るためのシステム機能はありますか？ファイルを解析するのは非効率的なようです。
答え1
あなたはファイルをコンテキストから抜け出すので、ファイルを解析するのは非効率的だと誤って考えます。以下の情報は、/procお客様がリクエストした場合にのみ「作成」されることを既にご存知ですが、いいえ変更があるたびに更新されます。したがって、それを解析するだけでなく、カーネルはそれをテキストとして生成する必要があります。
数バイトを直接 long に読み込むことは、atoi()文字列を呼び出すよりも確かに効率的です。ただし、これをシステムコールが実行されるコンテキストの一部として考慮する必要があります。一部のファイルの内容を読み取る（またはカーネルが提供できるいくつかのバイナリAPIを呼び出すために）、実行されるすべての追加コードは文字列変換に必要な時間を短縮します。
カーネルプロセスには通常のプログラムよりも頻繁に必要なデータがあるため、そのデータを取得するためにシステムコールを実行する必要があるオーバーヘッドはなく、これらのデータに直接アクセスできます。
答え2
どのような情報を取得したいのかについては言及していませんが、Linuxはpmap <pid>Solarisコマンドを再実装します。まったく同じ情報を印刷するわけではありませんが、出力は似ています。 LinuxがSolarisのさまざまなp *コマンドをさらに再実装したことを確認したいかもしれません。興味深いことにpsig、Linuxはそれをサポートしていません。
セキュリティ上の理由から、UNIXに関する特定の情報はプロセス自体でのみ使用できますps。
一般的なUNIXの哲学は、関数を通じて特別な情報を提供することでありioctl()、これは/proc1980年代後半に最初の実装が機能した方法でした。各プロセスは/ procのファイルであり、ioctlだけがこのファイルで動作します。 / procが導入される前に、UNIXユーザーは特別な情報を得るためにカーネルメモリを自由に読み取る必要があり、ロックがなかったため、関連プロセスが終了または交換されるとガベージが発生する可能性がありました。
1980年、UNOS（最初のUNIXレプリカ）はpsコマンドに対するgetpsinfo（）システムコールを実装しました。/proc抽象ビューのより良い実装として見ることができます。
1990年代半ば、procfs-2はプロセスをディレクトリとその中のファイルとして定義し、複雑なバイナリデータ（アドレス/proc/<pid>/as空間ファイルなど）を読み取ることができました。このディレクトリ内の他のファイルには、使用可能な構造化バイナリデータ（定義されたC構造）がありますread()（/proc/<pid>/usageリソースを使用するなど）。
Linuxはprocfsおよびprocfs2ファイルと互換性がありません。パス名が異なり、ファイルの内容が異なります。/proc/<pid>/fd/LinuxのAT&T procfs2ドキュメントと明らかな競合があります。