Linux カーネルは、Linux オペレーティング システム (OS) のバックボーンであり、コンピューターのハードウェアとそのプロセスの間の基本的なインターフェイスです。
数日前 変更の 1 つに関するニュースをここブログで共有します 発表会で分かること Linux カーネル 6.9 の、 これは現在開発中であり、さまざまな変更がすでに知られています。そして私たちが発表したのは、EXT2 はすでに廃止のカテゴリーに入り、古い NTFS ドライバーの使用は脇に置かれて、 Paragon Software によって開発されたドライバー。
今、 最新のニュースで Linux 6.9 が私たちに提供する新機能については、 このバージョンのカーネルでは、起動時間が大幅に改善されます。 大量の RAM を搭載したシステム、特に次のようなシステムを管理するユーザー向け これらは HugeTLB ページを利用します。 これにより、システムの起動プロセス中にこれらのページを初期化するのにかかる時間が大幅に短縮されます。
Linux 6.9で追加された変更 多数の HugeTLB ページを含むシステムで顕著な削減が可能になります。 開始時間に。たとえば、2 の 1800GB ページが初期化される 1TB システムでは、 現在、合計 1 秒のうち 2 ～ 10 秒かかります、これは間違いなく、この時代ではかなりの改善です。同様に、12 TB Intel ホストでは 11 の 776 GB ページが初期化されますが、初期化には 1 分以上かかる場合がありますが、起動時間の大幅な短縮が見られます。
これらの進歩 これらは、Bytedance の Linux 開発者 Gang Li 氏の献身的な取り組みによって可能になりました。 効率的な実行を確保するために複数のレビューを経た一連のパッチを実装しました。既存のカーネル インフラストラクチャ padata_do_multithreaded は、これらの結果を達成するために最小限の変更を加えて使用されました。
v6 では XNUMX つのアップデートが…
– together_bootmem_prealloc_node の潜在的なバグを修正しました
padata_do_multithreaded 実装では、それぞれの
together_bootmem_prealloc_node タスクはノードを処理します。ただし、説明されている API
コメントの padata_do_multithreaded は、padata_do_multithreaded もまた
複数のノードをタスク together_bootmem_prealloc_node に割り当てることができます。padata_do_multithreaded への今後の変更によって発生する可能性のあるエラーを回避するには、
together_bootmem_prealloc_Parallel は、
together_bootmem_prealloc_node。
利点 これらの改善点の中で特に重要なのは サービスの可用性とシステムの稼働時間が重要な環境で顕著です。 ハイパースケーラーや、非常に大規模なサーバーを管理する大規模な組織の場合と同様です。再起動時の起動時間の短縮は、より高速で効率的な稼働時間を確保する上で大きなメリットとなります。
それに加えて、 もう一つの変更点にも言及する価値があります これらは、Intel の経験豊富な Linux エンジニアによるパッチである Linux 6.9 に含まれています。 x86 キャッシュ リフレッシュにおけるメモリ帯域幅を制限するための改良された技術を導入これは、Intel が RDT および AMD EPYC CPU で resctrl コードを使用して使用するものと同様です。
パッチの作成者は次のように述べています。
MBA_mbps フィードバック ループは、グループがスキーマ ファイルで設定したユーザーよりも多くの帯域幅を使用している場合はスロットルを増やし、帯域幅が目標を下回っている場合はスロットルを減らします。
メモリ帯域幅を制限する新しい技術については言及する価値があります。 不均一な負荷レベルのワークロードをより効率的に処理するように設計されていますs、以前のバージョンのカーネルで発生した不必要なペナルティを回避します。
各反復における速度向上の不必要な変動を避けるために、「delta_comp」フラグを使用して、「delta_bw」の次の反復で記録される帯域幅の実際の変化を示します。現在の帯域幅に delta_bw を加えた値がユーザーの目標を下回っている場合にのみ、スロットルが削減されます。
そのように言及されているのは、 このアルゴリズムは、一定の帯域幅のワークロードでうまく動作します。 ただし、スロットリングが変更されたときにワークロードが変更されると、失敗する可能性があります。これに対処するために、スロットリングを次の高いレベルに下げた場合に帯域幅が増加する可能性を計算し、スロットルが下げられる前に帯域幅がユーザーの目標を下回るようにする、より単純な手法が実装されました。
もしあなたが それについてもっと知りたい、次のリンクで詳細を参照できます。