나는 최고의 컴파일 시간을 얻기 위해 GNU Make가 사용하도록 허용해야 하는 작업 수를 파악하기 위해 벤치마크를 실행하고 있습니다. 이를 위해 make -j<N>N이 1에서 17 사이의 정수인 Glibc를 컴파일했습니다. 지금까지 각 N 선택에 대해 이 작업을 35번 수행했습니다(총 35*17=595번). 나도 실행 중이야GNU 시간Make가 소요하는 시간과 사용하는 리소스를 결정합니다.
결과 데이터를 분석해 보니 뭔가 이상한 점을 발견했습니다. 내가 거기에 도착했을 때 주요 페이지 오류 수가 눈에 띄게 급증했습니다 -j8.
또한 8은 내 컴퓨터의 CPU 코어 수(또는 더 구체적으로 하이퍼스레드 수)라는 점에 유의해야 합니다.
자발적인 컨텍스트 전환 횟수에서도 같은 현상을 볼 수 있지만 눈에 띄지는 않습니다.
내 데이터가 왜곡되지 않았는지 확인하기 위해 테스트를 두 번 더 실행했지만 여전히 동일한 결과를 얻었습니다.
저는 Linux 커널 5.15.12를 사용하여 artix Linux를 실행하고 있습니다.
이러한 스파이크의 이유는 무엇입니까?
편집: 4코어 PC에서 동일한 실험을 다시 실행했습니다. 이번에는 4개의 직업에서 같은 현상이 관찰되었습니다.
또한 2개의 작업 표시에서 주요 페이지 오류가 급증한 것을 확인하세요.
편집 2:
@FrédéricLoyer는 페이지 오류를 효율성(소요 시간의 역수)과 비교할 것을 제안했습니다. 다음은 상자 그림입니다.
1개의 직업에서 4개의 직업으로 갈 때 효율성이 점점 더 좋아지는 것을 볼 수 있습니다. 그러나 더 많은 직업의 경우에는 본질적으로 동일하게 유지됩니다.
또한 내 시스템에는 충분한 메모리가 있으므로 최대 작업 수에도 불구하고 메모리가 부족하지 않습니다. 나는 또한 PRSS(피크 상주 세트 크기)를 기록했으며 여기에 이에 대한 상자 그림이 있습니다.
작업 수가 메모리 사용량에 전혀 영향을 미치지 않음을 알 수 있습니다.
편집 3: MC68020에서 제안한 대로 4코어 및 8코어 시스템에 대한 TLBS(트랜잭션 참조 버퍼 녹다운) 값의 플롯은 다음과 같습니다.
답변1
글로벌 효율성을 보여주는 그래프가 귀하의 작업에 대한 올바른 답을 제공하므로 집중적으로 설명하도록 노력하겠습니다.
A/ 효율성\작업 배치
이론적으로(make가 시작될 때 모든 CPU가 유휴 상태이고 다른 작업이 실행 중이 아니며 n > i가 시작될 때 i 작업이 완료되지 않았다고 가정) CFS가 1,2,3, Jobs 4,5를 배포할 것으로 예상할 수 있습니다. , 6, 7, 8은 CPU 0, 2, 4, 6(캐시 공유의 이점이 없기 때문에)에 할당되고 그 다음에는 1, 3, 5, 7(여전히 캐시 공유의 이점이 없지만 피어 간에 캐시가 공유되므로) , 잠금은 경합을 증가시켜 글로벌 효율성에 부정적인 영향을 미칩니다.) 이것이 작업 5부터 글로벌 효율성이 향상되지 않는 것을 설명하기에 충분합니까?
B/페이지 오류
Frédéric Loyer가 설명했듯이 작업 시작 시 주요 페이지 오류가 예상됩니다(필요한 읽기 시스템 호출로 인해). 차트에 따르면 일자리 5개에서 8개까지 성장이 거의 일정합니다. 내 의견으로는 4+4 코어에서 -j4의 상당한 증가(2+2 코어에서 -j2의 상당한 증가로 확인됨)가 더 흥미롭습니다. 이는 일부 <=4 CPU에서 갑작스러운 활동으로 인해(다른 작업으로 인해) > 4 CPU에서 작업 스레드가 다시 예약되었다는 증거일 수 있습니까? -j(n>8)에는 모든 선택적 CPU에 이미 적절한 매핑이 있으므로 페이지 오류 수가 일정합니다.
참고: 기타에 대한 내 요청을 정당화하기 위한 것입니다. OP의 의견에서 정보를 완화하여 먼저 모든 코어가 완전히 작동하는지 확인하고 싶습니다. 그런 것 같습니다.
답변2
프로세스가 시작 되면 make프로세스의 메모리가 해당 파일(실행 파일, 라이브러리)에 매핑됩니다. 그러면 페이지 오류가 예상됩니다. 시스템이 더 효율적일수록 더 많은 페이지 폴트를 예상할 수 있습니다. 페이지 오류율과 효율성(소요 시간의 역수 ) make을 비교하는 것은 흥미로울 수 있습니다 .
시스템에 RAM이 충분하지 않고 HDD와 데이터를 교환하는 경우에도 페이지 오류가 발생할 수 있습니다. 이것은 효율성의 표시가 아닙니다.