이번 주 월화수 3일간 포르투갈의 카스카이스(Cascais, Portugal) 열리는 ACM SOSP (Symposium on Operating Systems Principles) 학회에 다녀왔다. 비행기표 끊을 때 프랑크푸르트에서 환승하고 리스본으로 가는 비행기편이 아주 밤늦게 도착하는 것밖에 없어서 시차 적응 때문에 학회 당일 피로하지 않도록 하루 일찍 가는 편을 택했는데, 덕분에 포르투갈의 관광명소인 Sintra를 돌아볼 기회가 있었다. (온통 비바람 때문에 고생하긴 했지만... ㅠㅠ) 어쨌든, 관광에 대한 건 플리커 사진세트에 붙어있는 설명을 참고하고, 이 글에서는 학회 내용에 대한 것을 정리해볼 것이다.

내가 작년 이맘때쯤 갔던 OSDI에 대해 들어본 사람이라면 아마도 SOSP도 알 것이다. 이 두 학회는 각각 USENIX와 ACM이라는 두 단체가 거의 같은 내용을 가지고 격년제로 번갈아 여는데, 실제로 참여하는 학생들이나 연구자 커뮤니티는 똑같다. 역사는 SOSP가 훨씬 오래되었는데, 1967년부터 시작했으니까 시분할 시스템이라는 개념이 막 탄생하던 때쯤부터 이어져온 시스템 분야 최고의 학회이다.

이번에 내가 학회에 간 목적은 크게 1) 포스터(extended abstract, 사실 실제 발표한 포스터는 설명 흐름을 부드럽게 하려고 순서가 살짝 바뀐 부분이 있음) 발표와 socializing을 통해 PacketShader 후속 연구와 관련한 피드백을 받고 PTask 및 Click modular router의 저자와 직접 만나 홍보 및 의견 나누기 2) 내년 인턴십 자리를 위해 기업들 미리 찔러보기 요렇게 두 가지였다.

포스터 발표에 대한 반응은 작년과 비슷했는데, PacketShader를 알고 온 사람들은 차이점이 무엇인지 무슨 추가적인 work을 하려는 것인지 물었고, 모르고 온 사람들은 GPU의 자체의 특징에 대해서 물어보는 경우가 많았다. 어떤 사람은 "experimental platform"이라는 말에 꽂혔다면서(?) 자기가 Emulab testbed 참여하는데 어떻게 쓰일 수 있는 거냐 묻기도 했다. 새로운 아이디어에 대한 피드백은 딱히 없었다. 몇 가지 이렇게 해보면 어떻겠냐 라는 제안은 받았는데 우리가 연구 과정에서 생각해본 범위 내였다. 예를 들면 branching/diverse code path에 약한 GPU에서 하기 어려운 router pipeline을 통째 GPU에서 구현하면 어떨까 라든지, 현재는 proprietary driver로 인해 불가능한 NIC-to-GPU direct copy라든지.

그래도 PTask 저자였던 Christopher Rossbach와의 만남이나 Click modular router 만든 (지금은 하버드 교수인) Eddie Kohler와의 만남은 그 사람들의 생각이 어떤지 알 수 있어서 소기의 성과를 건질 수 있었다.

PTask는 GPU에 대한 추상화를 운영체제에서 직접 제공해야만 운영체제 스케줄링에서 GPU의 workload나 CPU interaction을 함께 고려할 수 있어 더 나은 성능과 performance artifact를 줄일 수 있다는 것이 핵심이고, 여기에 disjoint memory를 사용하는 GPU로 오가는 dataflow를 datablock이라는 덩어리와 port끼리 연결관계를 미리 정의해놓는 일종의 UNIX pipe 개념을 활용해 다단계 행렬 곱셈 등에서 발생하기 쉬운 중복 복사를 막겠다는 아이디어가 들어가있다.

내가 발표 끝나고 했던 질문¹은 datablock의 내용 변경 여부에 따른 GPU/CPU side의 invalidation 과정에서 datablock 통째로 하는 것이 좋을지 아니면 좀더 finer granularity (예를 들면 PacketShader에서는 한 datablock에 여러 개의 packet이 들어있을 수 있으니까)로 하는 것이 좋을지 물었는데, PCIe bus 타는 횟수를 줄이려면 자기가 한 것처럼 통째로 하는 게 좋지 않을까 라는 답을 들었다. 나중에 쉬는시간에 만나서 현재 Windows용 버전밖에 없는 것 같은데 공개할 계획이 있는지 물어보니 지금 코드는 MSR 내부 사정으로 공개가 불가능하나 참여한 대학원생들이 Linux 버전을 만들고 있다고 하고, PacketShader 팀하고 같이 일해보고 싶다고도 했다. 나중에 다른 사람들 얘기로는 PTask 연구의 문제점을 짚는다면 실제로 그러한 abstraction이 유용한 경우가 얼마나 있을 것인지 설득력이 다소 부족했다는 것을 들 수 있는데, PacketShader가 만약 PTask의 아이디어를 써서 큰 이득을 볼 수 있다면 대표 사례가 될 수 있기 때문이 아닐까 싶다.

Eddie Kohler를 만난 이유는, 내가 요 근래 Click + PacketShader-style HW optimization을 테스트해보면서 Click이 몇 가지 근본적인 한계가 있다는 것을 알게 되었기 때문이다. 그 한계란 약간의 코드 수정으로 NUMA-aware thread affinitization이나 IRQ pinning을 Click에 적용할 수는 있으나 싱글코어 시절 만들어져 나중에 멀티코어로 확장된 녀석이다보니 공통 데이터(router graph 등)에서 NUMA node crossing이 발생한다거나 user-level packet I/O가 특정 코어에서 병목이 된다거나(이건 pcap의 문제일 수도 있음) 하는 것들이다. 그래서 내가 물어본 것은 Click의 다음 step이 뭐라고 생각하는지였다. 그랬더니 대답 대신 질문이 되돌아왔는데, high-performace에 집중할 것인지 modularity + reasonable performance를 만들 것인지 아니면 정말 사람들이 쓰고 싶은 걸 만들 건지 알아야 한다는 것이었다. 어떻게 보면 모두 목표이긴 한데, 내 생각은 modularity는 적정한 수준까지만 쪼개고 performance에 집중하는 쪽이다. 아무튼 그러면서 덧붙이는 말이 자기는 Click의 performance를 위해 개발해온 게 아니라 correctness 쪽으로 집중해서 개발해왔다는 것. 결국 performance에 집중하려면 Click을 뜯어고치는 것보다는 새로운 코드를 짜는 게 낫다는 이야기였다.

어쨌든 직접 만나 이야기하니 재밌었다. 논문으로만 보던 사람들이 실제로는 어떤 사람인가 보는 것도 재밌고, 메일 주고받거나 하는 것보다 직접 눈앞에 두고 대화하는 것이 얼마나 더 효율적인지는 정말 안 해보면 모를 것이다.

다만 역시나 대화에 '적절하게' 끼어드는 것이 가장 어려운 일이었다. 이쪽 학회에 오는 서양 친구들은 기본적으로 '아무때나 끼어들어서 말 걸어도 괜찮아요' 모드인데 무언가 남의 말(그것도 교수님들 같은 윗사람들의)을 끊는 것이 실례라는 느낌을 항상 가지고 있는 동양 쪽 학생들로서는 언제 하고싶은 말을 어떻게 꺼내야 하는지 그 감이 잘 없다. 이럴 땐 두 가지 방법이 있는데, 에라 모르겠다 하고 끼어드는 방법이 있고 아니면 적당히 눈치를 줘가며(?) '이 친구가 뭐 말할게 있는 것 같은데' 하면서 알아서 끊어주기를 기다리는 방법이 있다. 문제는 인기있는 사람일수록, 말발이 좋은 사람일수록 전자가 어렵다는 것.

인턴십 관련해서는 아직 확정된 건 아무것도 없지만(내년에 울 교수님이 안식년 가시면 랩사람들을 대부분 인턴으로 내보내실 거라는 정도?) 일단 Facebook과 Google 쪽을 찔러봤고, 나중에 PTask 저자인 Rossbach나 다른 인맥을 통해 MSR도 찔러보려고 생각 중이다. 이런 학회에는 대개 스폰서 기업들의 비공식 recruiter들이 돌아다니기 때문에 나중에 실제 지원할지 어떨지는 몰라도 일단 눈도장이라도 찍어두는 셈이다. 내년에 "new" PacketShader가 어느 정도까지 논문이 될지 모르겠지만, 박사과정에서 인턴십을 간다면 기본적으로 논문을 쓸 수 있는 주제와 환경으로 가는 것을 교수님들이 선호하기 때문에 아마 그 연장선상의 일을 하는 쪽이 되거나, 그걸 응용·적용할 수 있는 약간 다른 토픽을 하는 쪽이 될 것이다.

논문 발표 중에서는 역시 내 논문과 가장 관련있는 PTask가 제일 기대되었지만 막상 발표는 그냥 그런 느낌이었고, 발표 스킬 자체만으로 본다면 MSR의 Jame Mickens라는 사람이 최고였다. Atlantis라는 Javascript/CSS/HTML parsing/rendering engine에 exokernel 개념을 도입한 웹브라우저에 대한 발표였는데, 문제 자체는 웹개발 좀 해본 사람이라면 누구나 아는 식상한 것이지만 그걸 너무나 재미있고 박력있게 풀어가서 그대로 몰입이 되었다. 발표들의 타입도 여러가지가 있었는데, Prezi를 이용해 화려하게 진행한 것부터 시작해서(개인적으로는 좀 산만하다는 느낌) 기술적인 디테일을 아주 상세히 다루거나 혹은 그 반대로 motivation과 evaluation만 보여주고 기술적인 내용을 질의응답으로 커버해버리는 경우까지 다양했다. Deterministic threading 발표가 많아 이게 화두인가 했는데, MIT 다니는 태수형 말로는 사실 강력한 motivation이나 usecase는 별로 없는데 일단 커뮤니티에서 어떻게 되는지 지켜보자는 느낌으로 근 몇년간 이쪽 논문들을 많이 뽑아서 보여주는 것 같단다. 기타 아이디어나 구현 방법이 모두 괜찮다고 생각되는 건 CryptDB 정도였고, 데이터분석을 통한 통찰로는 그와 함께 best paper 상을 받은 "File is not file" 정도가 있었다.

어쨌든 이 학회 통해서 느낀 건, 내가 누군가를 만나서 무슨 이야기를 해야겠다 하는 목적이 분명한 상태로 가면 훨씬 더 재미있게 사람들과 대화할 수 있다는 것이다. 비록 나와 정확히 같은 분야는 아니지만 그쪽의 아이디어를 내 연구에 어떻게 적용해보면 좋을 것 같다라든지, 혹은 근본적으로는 같은 문제를 어떻게 다르게 접근하는가 살펴보는 것이 직접적으로 연구와 관련되기 때문일 것이다. 얼른 1저자로 제대로 발표도 해보고 싶다.