12 ポイント 投稿者 GN⁺ 2025-04-22 | 2件のコメント | WhatsAppで共有
  • 米国のデータセンターの電力消費は2023年時点で国内電力の約4%を占め、2028年までに12%へ増加すると予測
  • ウォータールー大学の研究チームは、Linuxカーネルのネットワーク処理方式の改善を通じて、データセンターの消費電力を最大30%削減できる手法を開発
  • 核心はbusy polling方式の動的制御で、トラフィック状況に応じて割り込み方式とポーリングを自動で切り替える
  • この変更はわずか約30行のコード修正だけで実装され、Linux 6.13カーネルに正式に反映された
  • LinuxベースのデータセンターやWebサーバーに幅広く適用できる可能性があり、効率重視のソフトウェア開発という思想の回復を強調している

データセンターの電力消費、Linuxカーネルコードわずか30行で最大30%削減可能

電力消費増加への懸念

  • 世界のWebトラフィックの大半はデータセンターを通じて処理されており、これはAIサービスなどの高消費電力アプリケーションの基盤となっている
  • 米国では、2023年に電力の約4%をデータセンターが消費しており、2028年までに12%まで増加する見通し

問題の核心: Linuxカーネルのネットワーク処理方式

  • Linuxカーネルはネットワークパケット処理時に割り込み方式とポーリング方式を併用している
    • 割り込み: 新しいパケットが来るとCPUの作業を中断して処理
    • busy polling: 遅延を減らすためパケットの有無に関係なく定期的に確認 → 非効率

解決策: busy pollingを動的に切り替える

  • ウォータールー大学のマーティン・カルステン教授の研究チームは、ネットワークトラフィックに応じて
    • トラフィックが多いとき: busy pollingを使用
    • トラフィックが少ないとき: 割り込み方式に切り替え
  • その結果、不要な電力消費を減らし、柔軟性も向上

コード修正と適用状況

  • FastlyのエンジニアJoe Damatoと協力し、既存カーネルコードを並べ替える方法で実装
  • 新しいコードを書くことなく、既存構造の変更により約30行のコード修正で実現
  • Linux 6.13カーネル(2025年1月リリース)に正式に含まれた
    カーネルコミット

省エネ効果

  • ネットワーク中心のアプリケーションで最大30%の電力削減
    • 一般的なアプリケーションでは、これより削減率が低い可能性がある
  • トラフィック変化に自動適応するため、データセンターに最適化されている
  • LinuxベースのWebサーバー(nginx、Apacheなど)にも拡張可能

コミュニティへの波及とオープンソースへの影響

  • Damatoは関連技術をFastlyのH2Oサーバーにも適用する計画
  • オープンソースのカーネルコードであるため、他のWebサーバー開発者も参考にできる
  • エネルギー効率重視の開発文化の復活に向けた起爆剤となることが期待される

研究の哲学的意義

  • 「90年代にはリソース最適化がコンピューター工学の基本だった」が、この20年は性能重視に偏り、効率性が見過ごされてきた
  • この研究は「小さなコード改善が巨大な省エネにつながり得る」ことを示し、持続可能なソフトウェア開発の方向性を提示している

2件のコメント

 
GN⁺ 2025-04-22
Hacker Newsの意見
  • Linux には高性能ネットワーキングのためのビジーポーリング機能が追加されている。ほとんどの Linux ソフトウェアはこれを使わないが、データセンターで使われるソフトウェアでは、システムが忙しくないときに電力効率が悪くなる。このパッチにより、システムが忙しくないときはこれを無効にして、電力効率を回復できる。

    • 記事タイトルはやや誤解を招く。デスクトップ作業にも当てはまるように聞こえるが、実際にはデータセンター向けだ。タイトルに "in datacenters" という言葉を加えていれば混乱を避けられただろう。
  • 高性能なデータセンター処理の多くは、実際には Linux カーネルのネットワークスタックを通らない。

    • その代わりに DPDK、XDP、あるいは Onload や VMA のようなユーザー空間スタックを使う。SmartNIC がハードウェアオフロードを行うことも多い。こうした場合、このパッチは適用されない。
    • しかしこのパッチは、カーネルがデータパスに含まれる構成(CDN、イングレスノード、VM、組み込み Linux システムなど)では明らかに役立つ。すでに性能やレイテンシの問題からカーネルをバイパスしている処理には、大きな影響はないだろう。30% の省電力という見出しは、かなり条件次第だ。
  • この変更の詳細は https://lwn.net/Articles/1008399/ で確認できる。

  • 本当に素晴らしい変更だ。高性能計算の専門家として、非効率なコードによってどれだけのエネルギーが浪費されているのか、そしてコンピューティング規模が地球全体で拡大するにつれてそれがどれほど大きな問題になるのかを、私はよく考える。

    • 個人的には、コードは可能な限り効率的であるべきだという道徳的義務を感じている。特に、処理が数百個の CPU で何か月も実行されるような場合はなおさらだ。
  • 一方で Meta は、GPU を忙しく保つことで、LLM の訓練中の電力消費をより安定させるハックを持っている。たとえば、バッチ同期の際に大きな電力低下を起こしたくない。

  • これは、カーネルで「適応型割り込み緩和」がもはや使われていないことを意味するのだろうか。もう 15 年以上この種の作業には関わっていないが、ネットワーク速度が低いときは割り込みを使い、一定の閾値を超えたら割り込みを無効にしてポーリングを使う、という形でカーネルが適応していたはずだ。

    • 解決しようとしていた問題は、突発的で劇的なトラフィック変動だった。たとえば、スイッチングにループが持ち込まれ、それに伴うパケットストームが発生するような場合だ。この場合、割り込みがあまりに速く入りすぎて、システムが割り込みを無効化できるだけの非割り込み時間を十分に確保できなかった。したがって、Linux ルーターがネットワークインターフェースより多くのコアを持つようにすることが解決策だった。
  • 文に "Up To" が含まれていれば、文字どおり何でもありだ。

  • 話題とは外れるが、Joe Damato についての文章をまた読めてうれしい。昔を思い出す。James Gollick の tcmalloc に関する記事を最初に読んで packagecloud.io を知り、その後 Joe の素晴らしい記事群に出会った。

  • 核心となる段落:

    • "この省エネには注意点がある。『30% というのはネットワークスタックや通信部分に関する最良のケースです』と Karsten は説明する。『アプリケーションが主にそれを行っているなら 30% の改善が見られます。アプリケーションが他の作業を多く行い、ときどきネットワークを使う程度なら、その 30% はもっと小さな値になります。』"
  • この記事は昔を思い出させる : https://didgets.substack.com/p/finding-and-fixing-a-billion-bug

 
semanticist 27 일 전

おお~不思議ですね。
完璧なソフトウェアはやはり存在しないのだな、と思ったりもします。