▲

Linux 코드를 30줄만 수정하면, 전력 사용량을 최대 30% 절감할 수 있음

 (spectrum.ieee.org)
12P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 미국 내 데이터센터 전력 소비는 2023년 기준 국가 전력의 약 4%, 2028년까지 12%로 증가 예상
  • 워털루대 연구팀은 리눅스 커널의 네트워크 처리 방식 개선을 통해 데이터센터의 전력 소비를 최대 30% 절감할 수 있는 방안을 개발
  • 핵심은 busy polling 방식의 동적 제어로, 트래픽 상황에 따라 인터럽트 방식과 폴링을 자동 전환
  • 이 변경은 단 30줄 정도의 코드 수정만으로 구현, Linux 6.13 커널에 공식 반영됨
  • 리눅스 기반 데이터센터 및 웹서버에 광범위한 적용 가능성 존재하며, 효율 중심의 소프트웨어 개발 철학 회복을 강조함

데이터센터 전력 소비, 리눅스 커널 코드 단 30줄로 최대 30% 절감 가능

전력 소비 증가에 대한 우려

  • 전 세계 웹 트래픽 대부분은 데이터센터를 통해 이루어지며, 이는 AI 서비스 등 고전력 애플리케이션의 기반이 됨
  • 미국의 경우, 2023년 전력의 약 4%를 데이터센터가 사용, 2028년까지 12%까지 증가할 전망

문제의 핵심: Linux 커널의 네트워크 처리 방식

  • 리눅스 커널은 네트워크 패킷 처리 시 인터럽트와 폴링 방식 병행
    • 인터럽트: 새로운 패킷이 오면 CPU 작업 중단 후 처리
    • busy polling: 지연을 줄이기 위해 패킷 유무와 관계없이 주기적 확인 → 비효율

해결책: busy polling을 동적으로 전환

  • 워털루대 마틴 카르스텐 교수팀은 네트워크 트래픽에 따라
    • 트래픽 많을 때: busy polling 사용
    • 트래픽 적을 때: 인터럽트 방식으로 전환
  • 결과적으로 불필요한 전력 소모 감소, 유연성 증대

코드 수정과 적용 현황

  • Fastly 엔지니어 Joe Damato와 협업하여 기존 커널 코드를 재정렬하는 방식으로 구현
  • 신규 코드 작성 없이 기존 구조 변경으로 약 30줄 코드 수정
  • Linux 6.13 커널(2025년 1월 출시)에 공식 포함됨
    → 커널 커밋

에너지 절감 효과

  • 네트워크 중심 애플리케이션에서 최대 30% 전력 절감
    • 일반 애플리케이션은 이보다 절감율이 낮을 수 있음
  • 트래픽 변화에 자동 적응하므로 데이터센터에 최적화
  • Linux 기반 웹서버(nginx, Apache 등)에도 확장 가능

커뮤니티 확산 및 오픈소스 영향

  • Damato는 관련 기술을 Fastly의 H2O 서버에도 적용 계획
  • 오픈소스 커널 코드이므로, 기타 웹서버 개발자도 참고 가능
  • 에너지 효율 중심의 개발 문화 복원을 위한 기폭제 역할 기대

연구의 철학적 의미

  • “90년대에는 리소스 최적화가 컴퓨터공학의 기본”이었으나, 최근 20년간 성능 중심으로 치우쳐 효율성은 간과됨
  • 이 연구는 “작은 코드 개선이 거대한 에너지 절감으로 이어질 수 있음”을 보여주며, 지속가능한 소프트웨어 개발의 방향성을 제시함
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • Linux는 고성능 네트워킹을 위한 바쁜 폴링 기능을 추가했음. 대부분의 Linux 소프트웨어는 이를 사용하지 않지만, 데이터센터에서 사용하는 소프트웨어는 시스템이 바쁘지 않을 때 에너지 비효율적임. 이 패치는 시스템이 바쁘지 않을 때 이를 끄고 에너지 효율성을 회복할 수 있게 함.

    • 기사 제목이 다소 오해의 소지가 있음. 데스크톱 작업에도 적용될 것처럼 들리지만, 실제로는 데이터센터를 위한 것임. 제목에 "in datacenters"라는 말을 추가했으면 혼란을 피할 수 있었을 것임.

  • 고성능 데이터센터 작업의 많은 부분이 실제로 Linux 커널의 네트워크 스택을 거치지 않음.

    • 대신 DPDK, XDP, 또는 Onload나 VMA 같은 사용자 공간 스택을 사용함. 종종 SmartNICs가 하드웨어 오프로드를 수행함. 이러한 경우, 이 패치는 적용되지 않음.
    • 그러나 이 패치는 커널이 데이터 경로에 있는 설정(CDNs, 인그레스 노드, 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

답변달기