내 프로그램에는 프로세스와 함께 시작되어 프로그램이 끝날 때까지 남아 있는 여러 스레드가 있습니다. 애플리케이션 수명 동안 다양한 로드를 경험하며 때로는 모두 100%로 실행되기도 합니다.
기본적으로 Linux 스레드 스케줄러는 멀티 코어 시스템에서 이러한 스레드의 선호도를 매우 성급하게 변경합니다(IMO). 그래픽 프로세스 모니터(gnome의 모니터)에서 바운스 차트를 보면 이것이 일종의 오버헤드를 구성한다고 생각하지 않을 수 없습니다.
편집하다:명확히 하자면, 매우 안정적인 로드의 경우에도 스레드는 다른 코어에 예약되어 있으며, 이미지에는 표시되지 않더라도 각 스레드에 대해 선택된 코어가 종종 "교환"된다는 것이 매우 분명합니다.
이러한 선호도의 지속적인 변화가 성능에 부정적인 영향을 미치지 않습니까?
그렇다면 왜 이런 식으로 구현됩니까? 선호도를 변경하면 어떤 이점이 있나요?
내 추측은 다음과 같습니다
- 웨어 레벨링 – 하나의 코어에 모든 작업을 집중하지 마십시오
- 의도하지 않음 - 일부 스마트 알고리즘은 부하를 기준으로 사용량을 최적화하려고 시도하지만 선호도를 변경하는 대신 유지 관리를 보장할 만큼 오버헤드가 높지 않습니다.
답변1
하나의 코어에서 모든 스레드를 실행하려면 더 저렴한 단일 코어 하드웨어를 구입하십시오.
스케줄러는 모든 코어의 활용도를 최대화하려고 시도합니다. 이는 여유 시간이 있는 모든 코어에 스레드를 파견하는 것을 의미합니다. 한 코어에서 다른 코어로 스레드를 이동하는 데 드는 비용은 적으므로 스케줄러는 이를 방지하려고 노력합니다. 그러나 일반적으로 코어를 유휴 상태로 두지 않는 것의 이점이 스레드 마이그레이션 비용보다 훨씬 크기 때문에 이를 크게 인식하지 못합니다. 이는 스레드가 코어 로컬 캐시보다 더 많은 메모리를 사용하는 경우 특히 그렇습니다. 스레드가 사용하는 메모리가 코어 로컬 캐시에 없으면 이를 다른 코어로 마이그레이션해도 불이익이 없습니다.
Linux의 스케줄러와 같은 강력한 스케줄러에 대한 사후 평가는 성능을 저하시키는 경우가 많습니다.
표시되는 그래프는 개별 코어의 로드가 가득 차 있지 않고 약간씩 다르다는 것을 나타냅니다. 아마도 시스템 전체가 CPU 성능이 아닌 현재 실행 중인 작업에 의해 I/O가 제한되기 때문일 것입니다. 스레드가 한 코어에서 다른 코어로 얼마나 자주 이동하는지에 대해서는 어떤 식으로도 말하지 않습니다.
답변2
여기에 제공되는 스냅샷은 커널 유형(버전)에 따라 달라집니다. 이전 커널 버전 2.4는 친화력이 좋지 않아 시스템 성능에 영향을 미치는 스레드의 핑퐁 이동이 많이 발생합니다. 2.5부터 시작하는 커널 버전은 상대적으로 더 나은 친화력을 갖습니다.
멀티 코어 기반 시스템에서 선호도 설정은 코어 간에 스레드를 이동할 때 캐시 무효화를 방지하여 성능을 향상시킬 수 있습니다.
Linux 기반 멀티 코어 시스템에서는 애플리케이션 유형/요구 사항에 따라 프로세스의 경우 sched_setaffinity/taskset, 스레드의 경우 pthread_setaffinity_np를 사용하여 스케줄러의 선호도 동작(자연적 선호도)을 재정의할 수 있습니다.
커널 샤크멀티 코어 시스템과 유사성을 시각적으로 더 잘 표현하는 것 같습니다.
또한 주의사항맨 위선호도 설정(스케줄러 재정의)에 대한 시각적 지원을 제공합니다.