▲
GN⁺ 2024-08-27 | parent | ★ favorite | on: Linux 파이프 성능 저하(qsantos.fr)
Hacker News 의견

  • JMP가 RET로 대체되지 않는 이유는 CONFIG_RETHUNK 옵션 때문임

    • objdump의 디스어셈블리에서 RET가 JMP __x86_return_thunk로 대체된 결과를 볼 수 있음
    • 관련 링크: 링크1, 링크2

  • 함수의 시작과 끝에 있는 NOP 명령어는 ftrace가 추적 명령어를 삽입할 수 있게 함

    • ASM_CLAC와 ASM_STAC 매크로에서 나옴
    • X86_FEATURE_SMAP이 감지되면 런타임에 CLAC와 STAC 명령어로 채워짐
    • 관련 링크: 링크3, 링크4, 링크5

  • 한 사용자의 사이드 프로젝트는 파일 디스크립터를 위한 링버퍼를 제공하는 시스템 호출을 제안함

    • 파이프의 양쪽 끝이 링버퍼를 지원하면 동일한 링버퍼를 매핑하여 커널 호출 없이 제로 카피 IO를 가능하게 함
    • 협력자를 찾고 있음
    • 관련 링크: 링크6

  • Linux 파이프를 "느리다"고 부르는 것은 Toyota Corolla를 "느리다"고 부르는 것과 같음

    • 대부분의 경우 충분히 빠름
    • 극단적인 경우가 아니라면 더 빠른 것을 찾을 필요 없음

  • 현대 CPU에서는 rep movsb가 가장 빠른 벡터화된 버전만큼 빠름

    • 커널 함수 이름 "copy_user_enhanced_fast_string"이 이를 암시함
    • CPU 기능인 ERMS와 FSRM이 이를 가능하게 함

  • AVX512는 전력 소모가 많고 CPU 주파수 스케일링을 유발함

  • Hacker News의 "hug of death"를 다시 경험 중임

    • 캐싱된 WordPress 페이지 덕분에 상황이 나아졌지만 여전히 몇 초가 걸림

  • io_uring을 사용한 버전을 보는 것이 흥미로울 것임

    • 커널과 사전 공유 버퍼를 사용하여 복사를 피하고 시스템 호출 오버헤드를 줄일 수 있음

  • 블로그 로딩 시간이 약 20초 걸리는 것은 대담한 주장임

  • 거의 모든 형태의 IPC는 "느림"

    • 안전을 위해 성능 비용을 지불하기로 결정한 것임

  • 원래 splice가 왜 그렇게 느린지 이해하지 못했음

    • vmsplice보다 느린 이유를 지적했지만, 왜 그런지 명확하지 않음
    • vmsplice로 재구현할 수 없는 이유가 있을 것임