이는 다음과 관련이 있습니다.이 문제, 그런데 별로 만족스러운 답이 나오지 않아서 새로운 질문을 해볼 수 있겠다는 생각이 들었어요.
이 스크린샷은 하나의 코어가 100% 활용되었지만 상당한 양의 CPU를 사용하는 프로세스가 없음을 나타내는 htop을 보여줍니다.
나는 이것이 알 수 없는 이유로 커널이 너무 많은 CPU를 사용하고 있음을 의미한다고 생각하지만 이 문제를 조사할 좋은 방법을 찾지 못했습니다. (현재 eBPF를 고려 중) 이것이 내 디스크 암호화 및 디스크 액세스와 관련이 있을 수 있다고 생각했지만 iotop에는 중요한 디스크 사용량이 표시되지 않습니다. 저는 완전한 표준 커널로 Arch Linux를 실행하고 있습니다.
이 문제는 최근에 몇 번 발생했으며 재부팅하면 사라지고 표시되는 데 항상 최소 몇 시간이 걸립니다.
이 문제를 디버깅하는 방법이나 근본 원인에 대한 아이디어와 제안을 환영합니다.
편집하다:
따라서 이 새로운 스크린샷은 htop이 커널과 사용자 스레드를 모두 표시하도록 설정되어 있지만 여전히 높은 CPU 사용량에 대한 명확한 설명이 없음을 보여줍니다.
편집 2:
다음 스크린샷은 bfptrace실행 시 결과를 보여줍니다 bpftrace -e 'profile:hz:99 /cpu == 0/ { @[kstack] = count(); }'. acpi_os_execute_deferred어떤 이유에서인지 커널에 시간이 많이 걸리는 것 같습니다.
답변1
마침내 답을 찾았습니다. 문제는 똑같다는 것이 밝혀졌습니다이 문제추가정보가 있습니다여기그리고여기. 이 중 어느 것도 사용량이 0인 htop 문제를 언급하지 않으므로 이는 관련 없는 문제일 수 있습니다.
위의 링크에서 설명했듯이, 문제의 인터럽트를 사용 sudo grep . -r /sys/firmware/acpi/interrupts/하고 사용 echo "disable" /sys/firmware/acpi/interrupts/gpe6D하지 않도록 설정하는 것이 답입니다(제 경우에는 가장 높은 번호가 추가된 인터럽트 gpe6D).
이것이 문제인지 파악하기 위해 bfptrace질문에 설명된 대로 커널 스택 추적을 사용하여 CPU가 시간을 소비하는 위치를 알아낸 다음 bpftrace -e 'kprobe:acpi_ps_parse_aml /cpu == 0/ { printf("%d\n", tid); }'나열된 기능 중 하나에 대한 커널 스레드 ID를 찾았습니다. 문제의 스레드는 이라는 것이 밝혀졌고 kworker/0:3-kacpi_notify, 일부 인터넷 검색을 통해 다른 사람들도 해당 커널 스레드와 비슷한 문제를 겪었다는 사실이 밝혀졌습니다.