01. Overview of System Software Research

서울대학교 컴퓨터공학과 김진수 교수님의 "고급 운영체제" 강의를 필기한 내용입니다.

다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.

Computer systems §

• DBMS 도 일종의 Computer system 이라고 할 수 있다.
  • Application 의 측면이 있지만 이걸 사용하는 client application 이 있다는 점에서
• 요즘 연구 트렌드 상의 어려움…
  • 단순한 PoC 의 레벨이 아닌 실 사용자의 시스템 입장에서 specialty 가 있다는 것을 보여줘야 하기 때문에 어려워지고 있댄다.
  • 정말 많은 parameter 가 있기 때문에 항상 trade-off 가 있고 이것을 옳다고 명확하게 말할 수 있는 사람은 없기 때문

연구의 사이클 §

• 문제 정의
  • 최신에 정의되고 해결된 문제를 더 잘 푸는 것을 강점으로 내세우거나
  • 마찬가지로 그러한 문제에서 (맨 마지막에 future plan 등에서) 제기된 해결되지 못한 문제를 풀거나
    • 물론 위 둘의 경우에는 경쟁자가 많다: 모두 똑같은 생각을 하고 있기 때문
  • 새로운 문제를 정의 (e.g. 새로운 hw 출시에 따라 이것을 도입해 보는 것)
    • 물론 이건 로또맞는거나 마찬가지인듯
      • 이러한 새로운 문제를 발견하기에는 조상님이 잘 도와주지 않더라
    • 다음과 같은 예시를 생각해 볼 수 있다.
      • 메모리를 네트워크로 붙이는 CXL 이라는게 있는데
      • 속도는 느리지만 bw 는 큰 메모리 이고
      • 근데 속도가 느린 메모리를 위한 allocation policy 는 NUMA 라고 뭔가가 개발되어 있어서 이미 커널에 적용이 되어 있는데
      • 그럼 CXL 의 경우에는 뭘 더 해줘야 성능 향상에 도움이 될지 연구해보는 등
• 뭐 그 다음에는 “문제 해결 아이디어 정의” -> “디자인” -> “프로토타이핑” -> “측정” 의 과정을 거치는데
• 측정에서 뭔가 발전이 없으면 “분석” -> “최적화” -> 다시 “디자인” 으로 도르마무를 하는거다.
• 이렇게 수많은 사이클을 돌다 보면 둘중 하나의 결론이 난다: (1) 진짜 좋아지거나 (2) 포기하거나

문제를 파악하기 위해서는… §

• 뻔한 얘기지만 다른 분야도 좀 파악하고 있어야 되니라
• 최신 기술들을 팔로우업하고있어라… 싱기방기 (MS 의 Project Silica, MS 의 DNA Storage)
• 다양한 사람과 소통하며 피드백을 받자.
• 미리 대비해놓기
  • 아이디어가 생겼을 때 빨리 구현해볼 수 있도록
  • 뭐 관련 코드 읽어보기 등

디자인 §

• 문제와 해결방법이 구체화 됐으면 디자인해보자
  • Lampson’s hint (지난주에 준 논문) 에 이러한 디자인에 대한 방법론이 소개되어 있다.
    • 기능 (Functionality): 내가 원하는 기능이 작동할까?
    • 성능 (Speed): 속도가 빠르냐
    • 신뢰성 (Fault-tolerance): 신뢰할만하냐
      • End-to-end checking: 데이터를 주고 받을 때 chksm 같은 방법으로 데이터가 안깨졌는지 확인
      • 네트워크 뿐 아니라 메모리에서 디스크로 내려보낼때 등
  • Policy vs Mechanism
    • Policy (정책): (내)가 정한 “어떤” 것을 해야 하느냐: 바뀔 가능성이 있는 것
    • Mechanism: Policy 를 구현하기 위해서는 “어떻게” 작동해야 되는가
    • 뭐 이러한 예로 들면 쉬울 것 같다:
      • RoundRobin 은 Policy 이고 이걸 위한 Timer interrupt 는 Mechanism 이다
    • 이걸 구분짓는건 아주 중요: Policy 는 바뀔 가능성이 많기 때문에 이것만을 위한 Mechanism 을 만드는 건 비효율적이더라.
      • 다양한 Policy 를 커버할 수 있는 Mechanism 을 만드는 것이 좋을것이야.
      • 예를 들어서 Microkernel 은 기존의 monolithic kernel 의 fs, driver 같은거를 전부 다 때려박은 것과 다르게 policy-free 한 원초적인 것들만 구현해놓고 나머지 fs 같은건 전부 모듈식으로
        • 이 경우에는 application 에서 필요로 하는 모듈을 직접 적재해서 성능을 향상시킬 수 있게 할 수도 있다.
        • lustre 도 그쵸잉: lustre module 를 설치시에 적재

연구의 차별점 §

• 이것도 뻔한 얘기지만 논문이라는 것은 이것을 왜했고 다른것들과 차이점은 뭔지 설득하는 과정이더라.
  • “이미 많은데 왜 새로운 걸 들고왔는가”
• 어떻게 개선될 것이라는 것이라는 거를 (개선의 목표) 를 항상 생각하거라: 이런 생각 없이 고치기부터 하면 안된다 이거야.
• 뭐 더 좋게 하기 위한 방법들을 계속 생각

여기부터는 2024-03-12 강의

Evaluation §

• System 쪽은 실제로 만들고, 또 이것을 evaluation 하는 것을 중요하게 생각한다.
  • Network 쪽에서는 수학적 모델을 만들어서 하기도 하지만 system 쪽은 parameter 가 너무 많아 힘들다.
• Analytical investigations - 분석 모델 사용
  • 근데 위에서 말한 것 처럼 파라미터가 엄청 많기 때문에 아무래도 이것들로 공격이 들어올 때 잘 정당화 해야 된다.
• Simulation 사용
• 실제 시스템에서의 trace 나 log 들을 이용
• 프로토타입을 만들거나 기존의 시스템을 고치는 것은 아무래도 힘들다고 한다.
• 아니면 과학에서 사용하는 것처럼 가설 -> 검증 -> 수정 과정을 반복할 수도 있다.

Research paper §

• 논문을 읽을 때는 논문 발표 ppt 에 잘 정리되어 있으니까 계속 읽어보면서 참고하자.
• 핵심은 논문의 흐름, 스토리가 자연스럽게 이어져야 한다.
• 논문들을 많이 읽어보기
  • (교수님 추천) intro 까지 읽어보고 (여기 제시된 문제를 참고해서) 나라면 어떻게 했을까? 어떻게 해결했을까 생각해보는 것도 나쁘지 않다.

Evaluation criteria §

• 최신의 논문을 개선한 것이라면 그거랑 비교하면 되니까 별 문제가 없지만
• 문제를 새로 발견했다던가 기존의 문제를 좀 변형시킨 경우에는 결과를 비교할 만한 것이 부족할 수도 있다.
• “Novelty 가 없다” 라는 말의 의미는
  • “기존 논문에 비교해 새로울게 없다” 라는 의미가 아니고
  • “기존 논문이 있든 없든 그 분야의 사람들이 쉽게 생각해낼 수 있는 것이다” 라는 의미이다.
• Naive solution
  • 문제에 대해
  • 아직 적용한 사람은 없지만, 쉽게 생각할 수 있는 해결책(예를 들면 다른 분야에서 유사한 문제를 푼 방식)을 적용해 해결했다면 이것은 naive 한 해결책이다
  • 여기에다가 플러스 알파를 더 넣어야 진짜 specialty 가 있는 것