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