Linux 커널은 지난 15년 동안 실수로 최대 8코어로 하드코딩되었지만 아무도 눈치채지 못했습니다

원문 : Linux 커널은 지난 15년 동안 실수로 최대 8코어로 하드코딩되었지만 아무도 눈치채지 못했습니다 (thehftguy.com)

The Linux kernel has been accidentally hardcoded to a maximum of 8 cores for the past 15 years and nobody noticed

 

리눅스로 슈퍼 컴퓨터를 만드는 것이 아니였습니까? 😢

 

약간의 역사

최근에 Linux 커널 스케줄러에 대해 알아 보았습니다.

스케줄링에 대해 간략하게 소개하자면, 단일 CPU 단일 코어 시스템을 상상해 보십시오. 운영 체제는 응용 프로그램을 실행하기 위해 몇 밀리초의 시간 조각을 할당합니다. 모든 응용 프로그램이 때때로 몇 밀리초를 얻을 수 있다면 시스템은 대화형으로 느껴지고 사용자에게는 컴퓨터가 수백 개의 작업을 실행하는 반면 컴퓨터는 항상 1개의 단일 작업만 실행하는 것처럼 느껴집니다.

그런 다음 2000년대 초반에 멀티 코어 시스템이 소비자에게 저렴해졌고 대부분의 컴퓨터에는 2개 또는 4개의 코어가 있으며 운영 체제는 실제로 여러 작업을 병렬로 실행할 수 있습니다. 그것은 상황을 조금 바꿨지만 너무 많지는 않았지만 서버는 이미 서버에 여러 2 개 또는 4 개의 물리적 CPU를 가질 수있었습니다.

시간이 지남에 따라 코어 수가 증가했으며 2020년대 초반에 CPU당 128개의 코어가 있는 AMD 서버가 기준이 되는 상태에 도달했습니다.

일화의 경우, 역사적으로 Windows에서 기간은 약 16 밀리 초 였으며 절전 (1ms)을 수행하는 응용 프로그램이 약 16 밀리 초 후에 다시 시작되는 재미있는 부작용이있었습니다.

Linux 스케줄러

Linux, 짧고 단순화 된 버전으로 돌아갑니다.

Linux에서 커널 스케줄러는 5밀리초(멀티코어 시스템에서는 20밀리초) 단위로 작동하여 모든 애플리케이션이 다음 5밀리초 내에 실행될 수 있도록 합니다. 5밀리초 이상 걸리는 스레드는 선점되어야 합니다.

최종 사용자 대기 시간에 중요합니다. 평신도 용어로, 마우스를 이리저리 움직이고 마우스가 적어도 몇 밀리 초마다 화면에서 움직이면 컴퓨터가 반응하고 훌륭합니다. 그렇기 때문에 Linux 커널은 대화형 데스크톱 사용자에게 좋은 경험을 제공하기 위해 영원히 5밀리초로 하드코딩되었습니다.

CPU에 여러 개의 코어가 있을 때 스케줄러의 동작이 변경되어야 할 정도로 직관적입니다. 작업할 CPU가 여러 개인 경우 다른 작업을 실행하기 위해 항상 작업을 적극적으로 중단할 필요가 없습니다.

균형을 잡는 작업입니다. 작업을 중지하고 컨텍스트 전환을 유발하고 캐시를 중단하여 모든 작업을 느리게 만들기 때문에 몇 밀리 초마다 작업을 다른 코어로 다시 예약하고 싶지는 않지만 특히 최종 사용자가있는 데스크톱 인 경우 응답 성을 유지해야합니다.

스케줄러는 sysctl 설정으로 조정할 수 있습니다. 사용할 수 있는 많은 설정이 있으며, 소개는 이 문서를 참조하지만 커널이 실수로 8코어로 하드코딩되었기 때문에 모든 스케일링 번호가 잘못되었음을 알고 https://dev.to/satorutakeuchi/the-linux-s-sysctl-parameters-about-process-scheduler-1dh5

• sched_latency_ns
• sched_min_granularity_ns(커널 v6에서 base_slice로 이름이 변경됨)
• wakeup_granularity_ns

커밋합니다

이 커밋은 2009년에 코어 수에 따라 스케줄러 설정의 자동 크기 조정을 추가했습니다.

실수로 최대 8개의 코어로 하드 코딩되었습니다. 이런. 마법의 가치는 이전 커밋에서 비롯되며 그대로 유지되었습니다. GitHub의 전체 차이점을 참조하세요.

https://github.com/torvalds/linux/commit/acb4a848da821a095ae9e4d8b22ae2d9633ba5cd

흥미로운 설정은 최소 세분성으로, 시스템이 과부하 될 때 최소 0.75 밀리 초 (또는 멀티 코어 시스템의 경우 3ms) 동안 작업을 실행할 수 있도록합니다 (사용 가능한 CPU보다 더 많은 작업을 실행할 수 있음).

v6 커널의 이 커밋에서 min_granularity 설정의 이름이 base_slice로 변경되었습니다.

주석은 CPU 수에 따라 확장되며 주석이 잘못되었다고 말합니다. 커널 개발자가 스케줄러를 다시 작성할 때 그 실수를 알고 있는지 궁금합니다!

• 코드의 공식 주석에는 log2 (1 + cores)로 확장되고 있다고 나와 있지만 그렇지 않습니다.
• 코드의 모든 주석이 잘못되었습니다.
• 공식 문서 및 매뉴얼 페이지가 잘못되었습니다.
• 스케줄러에 대해 게시 된 모든 블로그 기사, 스택 오버플로 답변 및 가이드가 잘못되었습니다.

https://github.com/torvalds/linux/commit/e4ec3318a17f5dcf11bc23b2d2c1da4c1c5bb507

아래는 스케일링을 수행하는 함수입니다. 최대 8개의 코어로 하드 코딩된 코드입니다.

멀티 코어 시스템에서 최대 축척 계수는 4입니다.1+log2(min(cores, 8))

기본값은 로그 스케일링을 사용하는 것이며, 대신 선형 스케일링을 사용하도록 커널 설정을 조정할 수 있지만 8코어로 제한되어 있습니다.

https://github.com/torvalds/linux/blame/master/kernel/sched/fair.c#L198

최신 AMD 데스크탑에는 32개의 스레드가 있고 최신 AMD 서버에는 CPU당 128개의 스레드가 있으며 종종 여러 개의 물리적 CPU가 있습니다.

커널이 최대 8개의 코어(배율 4)로 하드 코딩된 것은 문제가 있습니다. 몇 밀리초마다 수백 개의 작업을 다른 코어, 다른 다이에서 다시 예약하는 것은 좋지 않습니다. 성능 및 캐시 지역성에 좋지 않을 수 있습니다.

결론적으로 커널은 지난 15년 동안 실수로 8코어로 하드코딩되었으며 아무도 눈치채지 못했습니다.

 

이런. ¯\_(ツ)_/¯