저는 Ubuntu에서 Measurement Compute DAQ를 사용하여 보드에 연결된 다른 시스템에서 연속적인 시뮬레이션 읽기 및 쓰기를 수행하고 있습니다. 저는 Ubuntu 16.04(Linux 커널 4.15로 업그레이드)를 약 5년 동안 사용해 왔습니다. 현재 시스템을 Ubuntu 20.04 - 22.04로 업그레이드하려고 합니다. 각 운영 체제에는 Linux 커널 5.10 - 5.15가 함께 제공됩니다. 나는 모든 커널 5.10 이상에서 매우 날카로운(약 50밀리초) 주기적인 인터럽트처럼 보이는 것을 발견했습니다. 따라서 A/D 보드의 시스템 read() 및 write() 호출에 영향을 미치는 5.9 커널에서 5.10 커널로의 일부 변경 사항이 있는 것으로 보입니다. 내 데이터 수집 소프트웨어에서 차이점을 확인할 수 있습니다.
내 평균 루프 시간 프로그램(연속적인 읽기 및 쓰기 호출을 수행하는 루프 - 그리고 그 사이에 일부 수학):
내가 본 최대 시간은 Linux 커널 5.9 이하의 경우 약 43마이크로초에서 Linux 커널 5.10 이상의 경우 50밀리초로 변경되었습니다. 분명히 이 문제를 해결하고 싶지만 어떤 변화로 인해 문제가 발생했는지 잘 모르겠습니다. 범인이 무엇인지, GRUB 부트로더에서 커널 매개변수를 변경하여 문제를 해결할 수 있는지 아는 사람이 있습니까? 어떤 조언이라도 감사하겠습니다. 감사해요!
편집하다:
DAC 출력을 업데이트하기 위해 write system 명령을 지속적으로 호출하는 최소한의 예를 구현했습니다.
DAC 쓰기 명령은 최소한 "get_user"를 호출하여 사용자 공간에서 커널로 데이터를 가져오고 "outw"를 호출하여 DAC 레지스터에 데이터를 씁니다.
이제 최소 예제를 실행할 때 연속 쓰기 시스템 명령을 실행하고 있으며 50밀리초의 지연이 있음을 알 수 있습니다.
그러나 시스템 명령 작성 사이에 1마이크로초 지연을 추가하면 50밀리초 지연이 사라집니다. 사용자 공간 정보에 액세스하려고 하거나 커널에서 장치에 너무 빨리 쓰는 것이 문제가 될 수 있습니까?
사용자 공간에 액세스하고 커널에서 장치로 데이터를 쓰는 사이에 커널이 수행하는 작업을 분석할 수 있는 방법이 있습니까?
답변1
내 컴퓨터에서 커널을 업데이트할 때 실시간 스레드에서 동일한 문제가 발생했습니다. 나에게 sysctl -w kernel.sched_rt_runtime_us=-1도움이 되었습니다 .
이를 깨는 변경 사항은 다음과 같습니다.RT_RUNTIME_SHARE는 기본적으로 비활성화되어 있습니다.
답변2
답변3
두 Linux 커널 사이의 우선순위 스케줄링에 약간의 변화가 있는 것 같습니다. 실행 중인 프로그램이 스케줄링 우선순위 90을 요청했는데, 이것이 인터럽트의 원인이었습니다. 우선순위 일정을 제거하거나 우선순위를 0으로 설정하면 인터럽트가 제거됩니다. 무엇이 바뀌었는지, 우선순위 스케줄링을 허용하는 솔루션이 어떤 모습일지 정확히 파악하지 못했지만 문제의 근본 원인은 파악된 것 같습니다.