ベストアンサー1
使用されるバイト数
他のカーネルコンポーネントと同様に、効率を向上させるために、メモリcgroupは、不要なキャッシュライン共有エラーを防ぐためにいくつかの最適化を使用します。 use_in_bytesはこの方法の影響を受け、メモリ（およびスワップ）使用量の「正確な」値を表示せず、有効なアクセスのファジー値です。 （もちろん、必要に応じて同期的に行われます。）より正確なメモリ使用量を知りたい場合は、memory.statのRSS + CACHE（+ SWAP）値を使用する必要があります（5.2を参照）。
正確な文書を読み、また読むと、そしてシステム性能がCPU使用率によって制限されることを測定した。 memory_usage サンプリングを検討できます。
どのように機能するのかわかりません。しかし、LWN.netの読者として、これは使用されている場所にローカルに残っている複数のカウンタがある可能性があり、何らかの方法でuse_in_bytesを読むことがこれらのカウンタの即時同期と要約を強制しない状況に似ています。
長年にわたり、カーネル開発者は、メモリ競合とそれに関連するパフォーマンスの低下を最小限に抑えるために、CPUあたりのデータをますます使用してきました。簡単な例として、ブロック層で維持するディスクジョブ統計を考えてみましょう。各ディスク操作のグローバルカウンタを増やすと、関連するキャッシュラインがプロセッサ間でバウンスされます。ディスク操作は、パフォーマンスコストを測定するのに十分な頻度で発生します。したがって、各CPUは独自のカウンタセットをローカルに維持し、カウンタの1つの値を増やすために他のCPUと競合する必要はありません。総数が必要な場合は、すべてのCPUあたりのカウンタが追加されます。カウンタは変更されるよりもクエリされる頻度がはるかに少ないため、これをCPUごとに保存するとパフォーマンスが大幅に向上する可能性があります。
-https://lwn.net/Articles/258238/
CPUが多くなく、cgroupを多く維持しない小規模なシステムを持っていれば、オーバーヘッドはそれほど大きくはないようです。 CPU間でいくつかのキャッシュラインをバウンスすることは費用がかからない。ただし、Googleがシステムで何千ものコンテナを実行している場合、またはシステムに何千ものCPUがある場合は、効率が役立ちます。