私は90年代後半からオープンソースIRCボットの開発者/維持管理者として活動してきました。目標は、常に小さなメモリ空間内でできるだけ多様で便利にすることです。
2000年代には、便利なプログラムを4kB RSSに圧縮した概念証明コードも書いていましたが、これは2.4カーネルで実装するのは難しくありませんでした。私はinitとAgettyを使ってこれを達成しました。つまり、単一の4kBメモリページ内に常駐して実行するようにしました。
ある日、ボットにメモリ使用量を報告するよう依頼したとき、ボットは次のように答えました。
[Mar 27 2018] <bot> VM 1000 kB (Max 2988 kB), RSS 4 kB [ Code 212 kB, Data 68 kB, Libs 556 kB, Stack 132 kB ]
カーネル2.4から4kB RSSを取得するには、すべてのコード、rodata、およびスタックセグメントを同じページにマップする必要があります。ボットを使ってこれを行うわけではないので、理論的な制限も12kBでなければなりません。しかし、それ以降のカーネルの場合、追加のアクセラレータマッピングがあるように見えるため、スタックとrodataがマッピング解除されても、12kBのマッピングが残ります。
ボットはlibmuslに接続されているため、54kBの「一般的な」標準RSSサイズで動作します。関数をほとんど使用されないコア必須チャンクに並べ替えるためにldスクリプトを作成しましたが、理論的には4kBはまだ意味がありません。システムは物理メモリが豊富でスワッピングやシステム負荷のないXeonなので、ページをスワップする必要があるという負担はありません。
ここで何が起こっているのか知っていますか？私はまだすべてを1つの4kBページに再マップする可能性に興味があります。しかし、これまでは再生可能な場合は12kB、再生不可能な場合は8kBまで減らしました。
ボットは/ procでRSSを読み、読み取った内容のうち変更されていない内容だけを報告します。ps auxボットが報告したのと同じVSZとRSSを表示します。
答え1
これは答えではありません。（コメントで編集するにはテキストが複雑すぎます）
あなたの質問に答えるには、まずシリーズ4でRSSとして報告された値が正確に何を意味するのかを正確に説明する必要があると思います。それは丁度何を示すか。
2.4以降、微積分学が（大きく）変更されたと確信しているからです。
私が覚えている最初の変更は、Andrew MortonとAlがRSSにいくつかのRLIMITを実装しようとしていた2.6時代でした。
バージョン:
- ioマップデバイスエリア
- 非線形マッピング
- 巨大な記憶力
- 共有汎用メモリ
- SysV-IPC共有メモリ
- 共有される共通メモリなし
私の記憶では、VM_IO部分をもう考慮しないことにすべてが同意し、共有ライブラリの全体のサイズを考慮しないという圧迫感も大きかったです。
他の部分（HugetLBとShared Normal Memory）は同意しにくいので、いくつかのサブカテゴリに分ける必要があります。
私がよく理解していなかった一種の毛皮の犬の物語。ちょうど4では、RSSの意味が2.4ではRSSの意味とは明らかに異なるため、同じ実行ファイルについて報告された値が非常に異なる可能性があることを指摘したかったのです。
頑張ってください。
もちろん、良い答えが投稿されたら、この投稿を削除します。