Application-Informed Kernel Synchronization Primitives

Ahn9807 (토론 | 기여)님의 2023년 2월 3일 (금) 06:56 판 (새 문서: 분류: 시스템 논문 OSDI 2022 'Application-Informed Kernel Synchronization Primitives' == 개요 == BPF와 Livepatch를 이용하여서, Application마다 달라지는 Locking Policy를 BPF Hooking을 통해서 구현 할 수 있다는 것을 보여준 논문이다. == Main Idea and Contribution == # BPF가 여러 다양한 분야에서 (이번엔 Lock)에서도 이용 될 수 있음을 보임 # Lock의 구현이 Application need마다 달라지는 경우가 많은...)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)


OSDI 2022 'Application-Informed Kernel Synchronization Primitives'

개요

BPF와 Livepatch를 이용하여서, Application마다 달라지는 Locking Policy를 BPF Hooking을 통해서 구현 할 수 있다는 것을 보여준 논문이다.

Main Idea and Contribution

  1. BPF가 여러 다양한 분야에서 (이번엔 Lock)에서도 이용 될 수 있음을 보임
  2. Lock의 구현이 Application need마다 달라지는 경우가 많은데, 해결방안을 Dynamic kernel pathcing을 통해서 해결함
  3. 잘못된 Lock구현에서 생길 수 있는 문제점들을 Safe API를 사용하면 방지할 수 있는 하나의 해결방안을 제시함
  4. 특히, Lock과 같은 Policy도 이러한 Generality와 Specialization에서 고려해야 함을, 최초로 해결방안과 함께 공개함

Criticizing

  1. 우선 논문에 나온 Figure처럼 Python의 아름다운 구조화가 사용된것이 아니라 매 Lock과정을 BPF Hooking Point로 만들어서 Hooking하고 있어서, 각각의 Operation마다 서로 다른 BPF File이 필요하다.
  2. 또한 Hooking Point가 qspinlock이라서 qspinlock에서 지원하지 않는 Operation이면 문제가 생긴다.
  3. 간단한 예제들 밖에 없어서, 복잡한 경우라면 어떻게 Handling할지가 궁금하다. 예를 들어서 논문을 읽고 SHFLLOCK을 다 구현하였다고 생각했지만, 기본적인 NumaNode에 관한 연산을 하고 있을 뿐이었다. 이런경우에 구현가능한지, 구현한다면 Benchmark에 어떤 영향을 미칠지 궁금하다.
  4. Figure에 마치 SHFLLOCK과 직접 비교하고 있는 것처럼 나오지만 매우 Minimal한 구현의 비교일 뿐이다. 즉 정확한 비교라고 할 수 없을 것 같다.
  5. 복잡한 Lock의 구현여부를 알 수 없다. 복잡한 알고리즘 혹은 개별 큐를 사용해야 할 경우 어떻게 할 것인가.
  6. Macro bench에서 다른 결과가 나올 수도 있을 것 같은데, Macro benchmark결과가 없다.
  7. unsafe API는 시스템 Pathcing을 Safe하게 한다는 eBPF의 철학과 위배된다. unsafe API에서 Recover할 수 있는 Method가 있으면 더 좋았을 것 같다.
  8. 사실, 다른 Kernel pathcing에서 안보여 줬을 뿐이지, 가능은 할것임