요약
Redox가 io_uring과 비슷한 링 버퍼를 구현해 I/O 벤치마크에서 동기 호출보다 14~15배 빨라졌습니다.
마이크로커널 운영체제 Redox 팀이 NLnet 재단의 지원으로 진행한 프로젝트를 정리한 글입니다. Redox는 I/O를 커널이 아니라 사용자 공간의 scheme 프로세스(드라이버나 파일 시스템 같은 서비스)에서 처리합니다. 그래서 애플리케이션이 이 프로세스에 비동기로 요청을 바로 넣는 통로를 만들었습니다.
왜 중요한가
- 애플리케이션과 대부분의 시스템 서비스를 링 버퍼로 잇겠다는 장기 목표의 첫 단계입니다.
- 팀은 IPC(프로세스 간 통신)가 아직 느리고 링 버퍼만으로는 그 비용을 다 상쇄할 수 없다고 봅니다. 그래서 커널 최적화를 함께 진행했습니다.
핵심 내용
- 제출 큐, 완료 큐, 버퍼 풀을 공유 메모리로 매핑해 데이터 복사를 피합니다.
- liburing을 참고한 API를 relibc에 넣고, RamFS와 NVMe 드라이버에 적용했습니다.
- IPC 왕복 지연 시간은 약 5,800사이클에서 약 2,700사이클로 줄었습니다.
- 스케줄러를 건너뛰는 직접 전환만으로도 IPC 지연 시간이 15~20% 줄었습니다.
- 드라이버용 비동기 실행기는 아직 코어 하나만 쓰며, 지금의 수치는 지연 시간의 대략적인 하한선으로 봐야 합니다.
HN 반응
- io_uring의 보안 문제가 해결됐다는 글의 설명에는 구글 버그 포상 제출의 60%가 이를 노렸고 안드로이드도 앱에서 막았다는 반론이 나왔습니다.
- 리눅스 7.0의 필터링 추가와 큰 성능 이득을 들어 위험이 과장됐다는 옹호도 있어, 의견이 갈렸습니다.
NVMe 큐와 그 아토믹 도어벨 head/tail 레지스터에서 두 단계 떨어진 이야기라는 점을 염두에 두고 읽으면 흥미롭습니다.
io-uring이 DMA-PRIME 지원을 추가하고, 그것도 NVMe부터 시작한 게(곧 나올 Linux 7.4에서) 우연이 아닐지도 모릅니다. https://www.phoronix.com/news/DMA-BUF-IO-uring-Linux-7.4
GPU도 지원을 추가하는 쪽으로 가길 바랍니다. 커널 중심적이라고만 느껴졌던 io-uring이, 주 메모리에 있지 않은 버퍼를 커널 오프로드로 옮기고 다루고 처리한다니 놀라울 따름입니다.
이거 멋지네요!!
스토리지 말고 또 어떤 분야가 이 덕을 볼 수 있을지 보고 싶어요. 블루투스나 비슷한 무선 쪽 같은 데요.
Redox 팀의 훌륭한 작업입니다. 러스트와 비동기 I/O를 다룬 아주 기술적인 블로그 글인데 4시간이 지나도록 댓글이 10개도 안 되는 걸 보면, 지금 실시간으로 실력이 퇴화하고 에이전트에 중독된 많은 HN 이용자에게는 너무 어려운 글인지도 모르겠습니다.
이 프로젝트는 어떤 형태의 AI 사용도 강하게 반대하니, 이 글의 내용은 코드를 읽어 보고 자기가 무엇을 하는지 아는 사람이 검토하고 썼다고 믿을 수 있습니다.
io_uring은 비동기 I/O에서 엄청나게 빠르지만, 리눅스 커널에서는 대형 보안 재앙이기도 합니다. Redox가 비동기 I/O를 안전하게 제공하는 인터페이스를 보여 줄 수 있다면 그만큼 좋은 일입니다. 아마 OS의 장기 목표에도 들어 있을 겁니다.
링 버퍼에서 출발해 전체적으로 개선해 나가는, 목표가 분명하고 사려 깊은 접근이 꽤 마음에 듭니다. 비동기 익스큐터 벤치마크 결과를 Linux와 비교해 보고, 거기서부터 개선을 이어 가야 합니다.
이 영역에서는 성능보다 완전한 정확성을 택한 흥미로운 접근입니다. Redox 커널에서 경쟁 상태나 해제 후 데이터 재사용 버그를 막는 데 러스트의 '보장'에 기대는 위험은 지지 않겠다는 뜻으로 읽힙니다.
제가 읽은 글 중 기술적으로 가장 탄탄하고 조사도 잘된 글 가운데 하나인데, 안타깝게도 HN에서는 품질 낮은 쓰레기 글들에 묻혀 버렸습니다.
io_uring이 보안 재앙이라는 말을 좀 자세히 설명해 주실 수 있나요? Redox 글에는 이렇게 적혀 있습니다.
글에는 io_uring이 사실 괜찮다고 설명하는 GitHub 토론 링크도 걸려 있습니다(https://github.com/axboe/liburing/discussions/1047#discussioncomment-8374809 참고).
(저는 어느 편도 아닙니다. 그냥 정확한 정보를 알고 싶어서 그런 거고, Redox 글을 읽고 io_uring이 안전하다고 마음을 정리했던 참입니다.)
Redox 글은 이 부분을 다소 축소해서 말하고 있습니다. 문제의 일부는 리눅스의 기존 시스콜 제한 체계(seccomp)가 io_uring에는 적용되지 않았다는 점입니다(지금도 그런지는 모르겠습니다). 그래서 io_uring이 구현한 시스콜의 비동기 버전은 전부 허용하거나 전부 막거나 둘 중 하나였습니다. 게다가 io_uring은 커널의 다른 부분에 비해 API 표면이 빠르게 늘고 있습니다. 이런 요인이 겹쳐 2019년 이후 보안 문제가 계속 터졌고, 예를 들어 안드로이드는 애플리케이션에서 io_uring을 아예 꺼 버리기까지 했습니다.
https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html
어차피 안드로이드 애플리케이션은 uring의 덕을 별로 보지 못할 거라고 생각합니다. 사람이 직접 쓰는 앱은 실제로 하는 일이 그리 많지 않으니까요. 예를 들어 네트워킹만 봐도 수백만 개의 연결/플로우를 수십 Gbit/s로 처리하는 게 아니라, 1~20개 플로우를 몇 Mbit/s 정도로 처리할 겁니다. 득을 볼 만한 프로세스 종류는 대체로 비교적 통제된 환경(예: 데이터베이스나 애플리케이션 서버)에 있기도 하고요.
7.0에서 일반 bpf 필터를 이용한 태스크 단위 필터링이 추가되었습니다.
https://lwn.net/Articles/1054225
좋네요!
io_urine이라고 불러야죠. 여기저기 새는 데다 두 가지 의미로 다 짜증 나게 하거든요. DMABUF에 연결하면 더 심해지고요. 90년대에서 아무것도 못 배웠네요...
추상적으로 보면 io_uring에 본질적으로 안전하지 않은 구석은 없습니다. 하지만 리눅스에서의 현실은 보안 재앙입니다. 각 서브시스템이 처음 만들어질 때 전혀 예상하지 못한 방식으로 io_uring이 거기에 끼어들어 상호작용하면서 온갖 버그를 드러내고 만들어 내기 때문입니다. 버그의 물결이 이제 과거의 일이라는 주장은... 성급했습니다. 버그가 완전히 멈춘 적이 없고, 일부는 io_uring 자체가 계속 커지고 복잡해지기 때문이기도 합니다.
기술적인 논평에 인신공격을 섞는 건 아쉽습니다.
Torvalds가 그걸 DMABUF랑 묶어 버렸잖아요. 어떻게 될지는 뻔하죠.
브랜치에서 가져온 리눅스의 차세대 메모리 서브시스템 쪽은, 러스트로 짠 Asterinas 쪽이 훨씬 앞서 있고 훨씬 안전해요. 윈도 98과 NT를 비교하는 것 같달까요.
스토리지 네트워킹과 GPU의 처리량이 몇 자릿수 더 오르고 효율이 극적으로 좋아진다는 말인가요?
저는 이걸 보고 환호하고 있어요. https://www.phoronix.com/news/DMA-BUF-IO-uring-Linux-7.4
망설이는 마음은 이해해요. 그런데 이런 공포, 불확실성, 의심(FUD)을 퍼뜨리고 보수적으로 구는 게 장기적으로 정말 이득이 된다고 생각하는 사람이 있나요?
io-uring이 장부에 쌓아 둔 성과는 대단해요. 어마어마하죠. 기적처럼 보여요. 서버 한 대가 할 수 있는 일을 완전히 바꿔 놨어요. 몇 자릿수나 더 많이, 그것도 CPU는 훨씬 적게 쓰면서요.
문제가 있었냐고요? 네, 있었어요. 지금은 완벽하냐고요? 아마 아니겠죠.
클라우드 사업자가 컨테이너에서 임의의 사용자 코드를 돌린다면, 미지의 것에 대한 두려움이 이해가 될 수도 있어요. 공개되지 않은 취약점이 악용돼서 자기와 고객이 당할 위험이 있으니까요. 하지만 대부분의 사람은 시스템에서 임의의 코드를 돌리지 않아요. 그리고 대형 취약점이 터져도 대부분의 사람은 표적이 되지 않고요. 제가 아는 한 과거의 이런 취약점 중에 실제 피해로 이어진 증거는 하나도 없어요. 좋은 일은 아니죠! 그런데도 사람들이 어떻게든 패배(L)를 선언하려고 얼마나 기를 쓰는지, 분노를 정당화하려고 자기도 남도 얼마나 몰아붙이는지 몰라요. 우스꽝스럽고 터무니없다고 생각해요.
성과는 이미 압도적이에요. 문제는 하나씩 해결되고 있고요. 문제의 빈도와 심각도도 줄어들어 이제 찔끔찔끔 나오는 수준이에요. 설계도 이걸 쓰는 소비자, 즉 프로그래머 입장에서 근본적으로 납득이 돼요. 하드웨어는 말할 것도 없이 이걸 좋아하고요. io-uring은 앞으로도 계속 이길 거고, 판을 싹 정리할 거예요.
그럼 해가 바뀌어도 바깥에서 시위 팻말을 흔들고 있는 반대파는 어떻게 될까요? 시간이 갈수록 점점 더 우스워질 수밖에 없다는 생각이 들어요. 시간이 지나면 io-uring 반대 시위는 세상 물정 모르는 코미디로 보이게 될 거예요. 성능을 30배로 끌어올려 주고, 우리 모두에게 납득이 되고, 우리 중 누구에게도 개인적으로 해를 끼친 적 없는 이 훨씬 나은 세상에서 사는 침묵하는 다수와는 완전히 동떨어진 채로요.
KSMBd도 같은 운명이에요(얻는 이득은 훨씬 적지만). 아마 끝까지 그것을 두고 소리 지르는 똑같은 공격견 같은 사람들이 있겠죠. 대체 뭘 위해서일까요? 정말 모르겠어요. 새로운 것이 자리 잡는 데는 때로 시간이 걸리기 마련인데 말이에요. 어떤 것에 소리를 지르고, 좌중의 관심을 가로채고, 군중보다 낫다고 느끼는 게 재미있으니까요. 역사는 죽지 않고, 원한과 어떤 것에 대한 나쁜 인상은 갱신되지 않으며, 부정적인 경험과 감정은 영혼에 새겨져 우리를 영원히 각인시킬 만큼 힘이 세니까요. 우리는 중심축에서 밀려나 영원히 어떤 것에 기울어 버리고, 재평가하고 다시 생각하고 새로운 현재가 무엇인지 돌아볼 가능성을 완전히 잃어요. https://en.wikipedia.org/wiki/Planck%27s_principle
우리는 시스콜 장벽을 그렇게 끊임없이 넘나들지 않아도 된다는 사실에 설렐 수 있고, 설레야 해요. 극적인 효율에 설렐 수 있고, 설레야 해요. 하드웨어에서 아주 잘 돌아가는 이 원형 버퍼들, 하드웨어와 호흡이 맞는 설계(mechanistic sympathy)에 설렐 수 있고, 설레야 해요. 대체로 우리는 영혼을 위해서라도 성공의 가능성을 직시하려고 노력해야 해요. 어둠 속에서도 언젠가 어쩌면 혹시나 빛과 은총과 성공이 들어설 자리를 남겨 둬야 해요. 저는 io-uring 말고 또 어떤 길이 있을지에 대한 이야기를 꼭 듣고 싶어요. 저는 io-uring을 알고 쓰고, 납득이 돼요. 제가 보기에는 아주 잘 작동하고요. 하지만 승리에 이르는 다른 아이디어가 있다면 알고 싶어요! 그래, 어쩌면이라는 상상에 함께하고 싶어요. 검증은 안 했지만 Asterinas가 있네요. https://github.com/asterinas/asterinas
Redox: Reduction and Oxidation(환원과 산화)
맞습니다. 그게 바로 녹(rust)을 만드는 화학 반응이고, 이 OS를 러스트(Rust) 프로그래밍 언어로 작성하고 있기 때문에 일부러 그런 이름을 붙인 겁니다. 그런데 왜 그 말만 달랑 댓글로 다셨는지는 잘 모르겠습니다. 잠깐 "이 제목에 맞는 댓글을 써라"라는 지시를 받은 봇인가 싶었습니다. 다른 글에 쓰신 댓글들을 보면 사람 같긴 합니다.
다르게 볼 수도 있습니다. 저는 기사를 읽다가 정확히 그 단어를 찾아봤습니다. 화학 맥락에서 본 지 꽤 오래됐거든요. 저와 같은 의문을 가진 사람이 있고, 그 사람이 시간을 들여 간결한 정의를 올려 줘서 반가웠습니다.
맞아요, 화학을 자주 접하지 않는 사람 중에는 Redox가 무슨 뜻인지 모르거나 잊어버린 사람도 많을 수 있잖아요.