time 명령은 4밀리초 타이머 틱에서 밀리초를 어떻게 계산합니까?

Question 1

당신이 읽을 수 있듯이일부 코드

#if defined (HAVE_GETRUSAGE) && defined (HAVE_TIMEVAL) && defined (RUSAGE_SELF)
...
  getrusage (RUSAGE_SELF, &self);
...
  print_timeval (stdout, &self.ru_utime);
...
#else
#  if defined (HAVE_TIMES)
...
  times (&t);
  print_clock_t (stdout, t.tms_utime);
...

HAVE_GETRUSAGE, HAVE_TIMEVAL 및 RUSAGE_SELF 설정에 따라 bash의 time내부 명령은 다음을 사용합니다.거트러세이지시스템 호출 또는이류시스템 호출.

getrusageCase를 사용하면 bash time명령은 rusage 구조의 ru_stime 및 ru_utime 멤버를 사용하고 위에 링크된 매뉴얼 페이지에 따라 연관된 timeval 구조의 멤버를 계산합니다.마이크로초 정확도.

times시스템 호출이 사용 되면 bash time명령은 관련 Clock_t 구조의 멤버를 출력합니다. 이 정확한 경우 값은 실제로 클럭 사이클로 보고되므로 보고된 값이 1/CONFIG_HZ보다 나을 수 없도록 올바르게 작성하는 방법이 있습니다.

times시스템 호출 매뉴얼 페이지에서 읽었을 수도 있지만 여러 가지 이유로 사용이 권장되지 않습니다. 그래서 저는 귀하의 시스템 설정(HAVE_GETRUSAGE...)이 bash가 이에 의지할 필요가 없도록 적합하다고 믿습니다. 그렇지 않다면... 당신 말이 맞아요. 당신이 보고한 정확도는... 우스꽝스럽습니다.

A/ getrusage가 1/CONFIG_HZ보다 타이밍을 더 정확하게 보고할 수 있는 이유: 왜냐하면:

Linux 2.6.21부터 Linux는 HRT(고해상도 타이머)를 지원합니다. HRT를 지원하는 시스템에서 절전 및 타이머 시스템 호출의 정확도는 더 이상 jiffy에 의해 제한되지 않지만 하드웨어가 허용하는 만큼 높을 수 있습니다. 마이크로초 정밀도는 최신 하드웨어의 전형입니다.

이 기사에서 읽을 수 있듯이시간 및 타이머 개요.

B/ 각 시스템 호출 시작 시 타이머를 적절하게 설정하고 완료 후 즉시 읽지 않고 어떻게 utime/stime에 대한 정확성을 얻을 수 있습니까?

정확한 CPU 시간:무슨 상관이야? 디스패처! 스케줄러완전히 공평하다속성을 공유하고, 작업 처리 의무를 잊지 말고, 기꺼이... nanosleep...
CPU 시간은 얼마입니까? :물론 총! 그것은 u_time + s_time입니다. 왜냐하면 (매우 드문 예외를 제외하고) 스케줄러는 작업이 어떻게(그리고 어떤 상황에서) 시간 조각을 낭비하는지 전혀 신경 쓰지 않기 때문입니다.
그렇다면 누가 s/u 시간 비율에 관심을 갖나요? : CPU회계매니아 여러분!

B.1/ 그럼... u_time과 s_time을 구별하나요? ...가설을...해보자!

(좋은?) 옛날 Linux(< 2.6.? 커널로 알고 있음)에서 CPU 계산은 일종의 단순한(ism?) 경험적 방법이었습니다. 일부 작업이 예약되면 스케줄러는 작업이 실행 중인 컨텍스트를 기록하고 ...:

CPU 회계사는 작업이 예약된 이후로 실행된 모든 시간이 예약된 시점에 실행 중이던 컨텍스트에서 소비되었다고 가정할 것입니다.

이것으로부터 시계의 정확성으로 인해 사용자 및 시스템 CPU 시간에 대한 개별 보고서의 정확성에 대해 논쟁하는 것은 다소 무의미하다는 것을 이해할 수 있습니다. 무엇이 무엇인지 결정하는 데 단순히 오류가 있습니다. 시간이 지남에 따라 오류가 누적됩니다. 작업 수명 동안 작업이 예약되거나 취소되는 횟수를 추가하는 것이 CPU 시간 통계 매니아에게 도움이 될 수 있는 유일한 기회는 +의 오류가 -의 오류를 보상할 것이라고 기대하는 것입니다. 따라서 이 값의 의미는 무엇이든( 별도로 고려되므로 합계는 사실이고 정확하며 의미가 있습니다)

B.2/ 버그는 괜찮지만... 그다지 심각하지는 않습니다! 그럼... 시작해 봅시다... 가상으로!

가상 CPU가 있는 시스템에서 실제 CPU보다 더 많은 가상 CPU가 가상 플랫폼에서 사용되는 경우 실제 CPU는 다른 가상 프로세서를 서비스하는 데 시간의 일부를 소비할 수 있으며 실제로 프로세스를 활용할 수 없는 무언가가 타임 슬라이스를 차지할 수 있습니다. 가득차 있는.
이로 인해 부정확할 뿐만 아니라 완전히 비현실적인 s_time 수치가 생성됩니다.

간단히 말하면 2.6정도 됩니다. ? 커널, 리눅스와 함께 제공가상 CPU 시간 통계다른 기능 중에서도 실행 컨텍스트가 변경될 때마다 CPU 시간 통계를 제공하여 모호하지 않고 정확하며 정확한 u-time 및 s-time을 가능하게 합니다.

모든 것과 마찬가지로 공짜 점심은 없습니다... (CPU당) 타이머는 어디에나 있습니다... 상당한 오버헤드가 예상됩니다.

신경 쓰지 마세요. 많은 상위 배포판(RHEL, SUZE...)에서는 곧 이 가상 CPU 시간 통계를 기본값으로 설정했습니다.

3.7부터 사용할 수 있는 일부 커널 튜너블( CONFIG_TICK_CPU_ACCOUNTING ) 덕분에 (개인적으로는 중요하지 않습니다. AFAIK는 여전히 재고 Linux 빌드의 기본값입니다.) 여전히 (좋은?) 오래된 cheep CPU 계산 방법을 선택할 수 있습니다. .. ..저는 (개인적으로) u_time + s_time의 합에만 관심이 있습니다.

이것은 모두가 될 것입니다 ;-)

Answer