メモリマネージャはシステムのサブセットです オペレーティング オペレーティングシステムとさまざまなアプリケーション間でメモリを共有します。 メモリという用語は主にメインメモリ（RAM）を指しますが、その管理には補助メモリとキャッシュメモリの貢献が必要です。
メモリマネージャー プロセスにメモリを効率的に割り当てることに特に責任があります、これは、使用可能なメモリの空き場所を列挙し、新しいプロセスに必要なメモリを割り当て、終了するプロセスからメモリを再利用できる必要があることを意味します。 Linuxカーネル内のプロセスディスパッチャーはSLABディスパッチャーです。
スラブ メモリ要求を最適化するブロックおよびキャッシュシステムに依存しています。 このタイプのメモリ管理は、割り当ておよび再配置操作によって引き起こされる断片化を減らします。
ブロック割り当てには、特定のオブジェクトに適した固定サイズの断片にカットされたいくつかの事前に割り当てられたメモリブロックを持つ特定のオブジェクトタイプ/サイズのキャッシュを実装することが含まれます。
SLABは、カーネルがオブジェクトにメモリを割り当てるように要求されたときに、ピースを管理します。 既存のブロックのスペアパーツでその要求を満たすことができます。 SLABは、同様のオブジェクトの後続の割り当て時に再利用するために割り当てられたメモリを保持するため、オブジェクトの初期化に関連するオーバーヘッドコストを削減します。
彼らはSLABを置き換えるつもりです
ローマン・グシュチン、 FacebookのLinuxカーネルエンジニアリングチームのメンバーである彼は、現在のメモリマネージャー/コントローラーに「重大な欠陥」と見なされているものを発見しました。 そしてr最近、新しいメモリコントローラーを提案しました ブロック これは、複数の「cgroup」間のメモリ使用率を劇的に改善することを約束します （またはコントロールグループ）メモリから。
これを考えると、cgroupsは、システムのリソース（プロセッサ、メモリ、ディスク使用量など）の使用を制限、カウント、および分離できるLinuxカーネルの機能と、「スラブのページ」という用語を指すことに注意することが重要です。 SLABによるメモリ割り当てプロセスに同化される可能性があります。
Gushchinによると：
「既存の設計がSLABの使用率を低くする本当の理由は単純です。スラブのページは、単一のメモリプールによって排他的に使用されます。
cgroupによって行われた特定のサイズの割り当てがわずかしかない場合、cgroupが削除された後にアクティブなオブジェクトが残っている場合、またはcgroupにカーネルを実質的に割り当てないシングルスレッドアプリケーションが含まれている場合、新しいCPU：これらすべての場合において、結果として生じるSLABの使用量は非常に少なくなります。
kmem計算が無効になっている場合、カーネルは他の割り当てのためにタイルページの空き領域を使用できます«。
Gushchinは、各メモリプールで有効にする必要のあるオプション機能としてkmemドライバーが導入された場合、これは問題ではなかったと主張しています。
しかし今は、kmemドライバーは、cgroupv1およびv2に対してデフォルトで有効になっています。 また、最近のシステムでは多数のcグループが作成される傾向があるため、SLABの使用はあまり効果的ではありません。
彼によると、さまざまなメモリグループ間でスラブページを共有することによって そして、会計がページではなくオブジェクトによって行われる再加工されたシステムを使用することによって、 Linuxカーネルには最適化されたメモリコントローラーがあります これにより、はるかに効率的なレベルの使用が可能になります。
Gushchinが提案するパッチには、XNUMXつの半独立した要素が含まれています。XNUMXつは将来アカウンティング目的で使用できるサブページロードAPI、もうXNUMXつはmem_cgroup_ptrAPIです。
新しいコントローラーで実行されたテスト グシチンの記憶 Linuxでは35％から42％多くのメモリを取得できることが示されています フロントエンドWeb、DNSサーバーとデータベースキャッシュ、およびその他の多くのワークロード。
Gushchinの提案は、現在「コメントのリクエスト」のバナーの下にあります。 承認されれば、2020Linuxカーネルリリースに統合できます。