배경:

GPIO 핀이 전환될 때까지 기다리기 위해 사용자 공간 코드에서 pselect 시스템 호출을 사용합니다. 나는 이 스위치가 발생하는 데 5밀리초 이상 걸리지 않아야 한다는 것을 알고 있으며 오실로스코프를 사용하여 이를 확인했습니다. 그러나 혼란스럽게도 pselect 호출이 반환되는 데 최대 20밀리초가 걸리는 경우가 있습니다.

조사:

적중 시 현재 시간을 모두 인쇄하도록 GPIO 드라이버, 커널의 pselect 구현, glibc 라이브러리의 pselect 구현을 수정했습니다. 이를 사용하여 GPIO 드라이버와 커널의 pselect 구현이 적시에 적중한다는 것을 확인했습니다. 그러나 반환되는 커널 pselect 호출과 커널에 대한 glibc 시스템 호출 바로 다음 행 사이에는 6~15ms의 간격이 있습니다.

C 라이브러리에서 시스템 호출이 구현되는 방식에 대해 내가 이해한 것은 아키텍처별 매크로 "INLINE_SYSCALL"이 사용자 모드와 커널 모드 사이에서 CPU를 전환하고, 인수를 커널에 전달하고, 실제로 커널 함수를 호출한 다음 errno 설정을 처리한다는 것입니다( 해당되는 경우). ARM에서 이 로직은 몇 가지 어셈블리 명령어인 것 같은데, 시간이 거의 걸리지 않을 것으로 예상됩니다.

하드웨어와 소프트웨어:

저는 ARM Cortex A9에서 실행되는 커널 버전 4.1.33(선점 실시간 패치 포함)과 glibc 버전 2.23을 사용하고 있습니다.

질문):

커널 함수에서 반환되는 줄과 glibc가 상당한 시간 손실을 설명할 수 있는 커널을 호출한 후 줄 사이에 무슨 일이 발생합니까?

이 시간 손실의 원인을 더욱 좁히기 위해 실행할 수 있는 다른 테스트가 있습니까?

업데이트/편집:

온전한 상태를 확인하기 위해 pselect 로직을 가능한 한 빨리 GPIO 핀의 값을 요청하는 긴밀한 사용 루프로 일시적으로 교체했습니다. 루프는 gpio 핀 값의 변화가 관찰될 때만 종료되며 항상 5밀리초 내에 종료됩니다. 이는 pselect가 실제로 문제임을 나타냅니다.

몇 가지 추가 테스트를 거친 후 폴링 시스템 호출이 기본적으로 pselect와 동일한 작업을 수행하지만 pselect를 사용할 때 관찰되는 시간 불이익을 겪지 않는 것으로 나타났습니다. 그래서 문제는 해결할 수 있었지만, 그래도 가능하다면 원인을 알고 싶습니다...