The logs are flooded with pfe_khms_spurious_wakeup kernel logs.

Flooding of kernel messages "pfe_khms_spurious_wakeup" may be observed along with eventd CPU spikes.

*** messages ***

Jun 24 20:13:34 EX4300-switch /kernel: peer_master_work: 5750: pfe_khms_spurious_wakeup: 74187 Peer (class: 0, type: 17, index: 0, vksid: 0, state: 1 pfe_stats_spurious_wakeup: 74187 )

Jun 24 20:13:34 EX4300-switch /kernel: peer_master_work: 5750: pfe_khms_spurious_wakeup: 74188 Peer (class: 0, type: 17, index: 0, vksid: 0, state: 1 pfe_stats_spurious_wakeup: 74188 )

Jun 24 20:13:34 EX4300-switch /kernel: peer_master_work: 5750: pfe_khms_spurious_wakeup: 74189 Peer (class: 0, type: 17, index: 0, vksid: 0, state: 1 pfe_stats_spurious_wakeup: 74189 )

root@EX4300-switch> show system processes extensive | match eventd | refresh 10

---(refreshed at 2024-06-24 20:15:33 UTC)---

1262 root       76  0  294M  276M RUN   1:32 86.82% eventd

---(refreshed at 2024-06-24 20:15:43 UTC)---

1262 root       71  0  294M  276M RUN   1:38 88.18% eventd

---(refreshed at 2024-06-24 20:15:53 UTC)---

1262 root       76  0  294M  276M RUN   1:45 88.13% eventd

The problem is caused by the Peer-Proxy thread catching a random signal. The log messages are harmless themselves. However, due to the excessive logging, the EVENTD process may spike. You may filter these messages to prevent them from filling up the logs but this does not reduce the CPU load. The workaround is to reboot the RE. This issue has been addressed via PR1801535.