Linux는 고성능 네트워킹을 위한 바쁜 폴링 기능을 추가했음. 대부분의 Linux 소프트웨어는 이를 사용하지 않지만, 데이터센터에서 사용하는 소프트웨어는 시스템이 바쁘지 않을 때 에너지 비효율적임. 이 패치는 시스템이 바쁘지 않을 때 이를 끄고 에너지 효율성을 회복할 수 있게 함.
기사 제목이 다소 오해의 소지가 있음. 데스크톱 작업에도 적용될 것처럼 들리지만, 실제로는 데이터센터를 위한 것임. 제목에 "in datacenters"라는 말을 추가했으면 혼란을 피할 수 있었을 것임.
고성능 데이터센터 작업의 많은 부분이 실제로 Linux 커널의 네트워크 스택을 거치지 않음.
대신 DPDK, XDP, 또는 Onload나 VMA 같은 사용자 공간 스택을 사용함. 종종 SmartNICs가 하드웨어 오프로드를 수행함. 이러한 경우, 이 패치는 적용되지 않음.
그러나 이 패치는 커널이 데이터 경로에 있는 설정(CDNs, 인그레스 노드, VM, 임베디드 Linux 시스템 등)에서는 분명히 도움이 됨. 이미 성능이나 지연 시간 문제로 커널을 우회하는 작업에는 큰 영향을 미치지 않을 것임. 30% 전력 절감이라는 헤드라인은 매우 상황에 따라 다를 것임.
정말 멋진 변화임. 고성능 컴퓨팅 전문가로서 비효율적인 코드로 인해 낭비되는 에너지가 얼마나 되는지, 그리고 그것이 행성 컴퓨팅이 확장됨에 따라 얼마나 큰 문제가 되는지 자주 궁금했음.
개인적으로, 코드가 가능한 한 효율적이어야 한다는 도덕적 의무를 느끼고 있음. 특히 작업이 수백 개의 CPU에서 몇 달 동안 실행될 때 더욱 그러함.
반대로, Meta는 GPU를 바쁘게 유지하여 LLM 훈련 중 전력 소모가 더 안정적이도록 하는 해킹을 가지고 있음. 예를 들어, 배치 동기화 시 큰 전력 감소를 원하지 않음.
이것이 커널에서 "적응형 인터럽트 완화"가 더 이상 사용되지 않는다는 의미인가? 약 15년 이상 이와 관련된 작업을 하지 않았지만, 네트워크 속도가 낮을 때는 인터럽트를 사용하고, 특정 지점을 넘으면 인터럽트를 끄고 폴링을 사용하는 방식으로 커널이 적응했었음.
해결하려고 했던 문제는 갑작스럽고 극적인 트래픽 변화였음. 예를 들어, 스위칭에 루프가 도입되고 관련된 패킷 폭풍이 발생하는 경우. 이 경우, 인터럽트가 너무 빨리 들어와 시스템이 인터럽트를 비활성화할 수 있는 비인터럽트 시간을 충분히 확보할 수 없었음. 따라서 Linux 라우터가 네트워크 인터페이스보다 더 많은 코어를 갖도록 하는 것이 해결책이었음.
문장에 "Up To"가 포함되면, 문자 그대로 모든 것이 가능함.
주제와는 다르지만, Joe Damato에 대한 글을 다시 읽게 되어 기쁨. 과거의 기억이 떠오름. 처음 James Gollick의 tcmalloc에 대한 글을 읽고 packagecloud.io에 대해 알게 된 후 Joe의 놀라운 글들을 접하게 되었음.
핵심 문단:
"이 에너지 절감은 주의사항이 있음. '30%는 네트워크 스택이나 통신 부분에 적용되는 최상의 경우임,' Karsten이 설명함. '애플리케이션이 주로 그것을 수행하면 30% 개선을 볼 수 있음. 애플리케이션이 다른 작업을 많이 하고 가끔 네트워크를 사용하면 30%는 더 작은 값으로 줄어들 것임.'"
Hacker News 의견
Linux는 고성능 네트워킹을 위한 바쁜 폴링 기능을 추가했음. 대부분의 Linux 소프트웨어는 이를 사용하지 않지만, 데이터센터에서 사용하는 소프트웨어는 시스템이 바쁘지 않을 때 에너지 비효율적임. 이 패치는 시스템이 바쁘지 않을 때 이를 끄고 에너지 효율성을 회복할 수 있게 함.
고성능 데이터센터 작업의 많은 부분이 실제로 Linux 커널의 네트워크 스택을 거치지 않음.
이 변화에 대한 자세한 내용은 https://lwn.net/Articles/1008399/ 에서 확인할 수 있음.
정말 멋진 변화임. 고성능 컴퓨팅 전문가로서 비효율적인 코드로 인해 낭비되는 에너지가 얼마나 되는지, 그리고 그것이 행성 컴퓨팅이 확장됨에 따라 얼마나 큰 문제가 되는지 자주 궁금했음.
반대로, Meta는 GPU를 바쁘게 유지하여 LLM 훈련 중 전력 소모가 더 안정적이도록 하는 해킹을 가지고 있음. 예를 들어, 배치 동기화 시 큰 전력 감소를 원하지 않음.
이것이 커널에서 "적응형 인터럽트 완화"가 더 이상 사용되지 않는다는 의미인가? 약 15년 이상 이와 관련된 작업을 하지 않았지만, 네트워크 속도가 낮을 때는 인터럽트를 사용하고, 특정 지점을 넘으면 인터럽트를 끄고 폴링을 사용하는 방식으로 커널이 적응했었음.
문장에 "Up To"가 포함되면, 문자 그대로 모든 것이 가능함.
주제와는 다르지만, Joe Damato에 대한 글을 다시 읽게 되어 기쁨. 과거의 기억이 떠오름. 처음 James Gollick의 tcmalloc에 대한 글을 읽고 packagecloud.io에 대해 알게 된 후 Joe의 놀라운 글들을 접하게 되었음.
핵심 문단:
이 글은 과거의 기억을 되살려 줌 : https://didgets.substack.com/p/finding-and-fixing-a-billion-bug