<div dir="ltr"><div>Hi Simon, Andrew,</div><div><br></div><div>Let me provide some context. We have a platform with a Qualcomm SA522M chip and an 88Q2221MB2 Marvel Ethernet PHY. We use the ptp4l application to synchronize the local /dev/ptp0 clock with the time from an external grandmaster (802.1AS-2011 gPTP time synchronization). Ptp4l is part of the open-source LinuxPTP project. We have observed a very high CPU usage by ptp4:<br><br>02:21:24 UID PID %usr %system %guest %wait %CPU CPU Command<br>02:21:25 1072 1660 0.00 8.00 0.00 1.00 8.00 0 ptp4l<br>02:21:26 1072 1660 0.00 9.00 0.00 0.00 9.00 0 ptp4l<br>02:21:27 1072 1660 0.00 9.90 0.00 0.99 9.90 1 ptp4l<br>02:21:28 1072 1660 0.00 7.00 0.00 0.00 7.00 1 ptp4l<br>02:21:29 1072 1660 0.00 9.00 0.00 0.00 9.00 0 ptp4l<br>02:21:30 1072 1660 0.00 9.00 0.00 1.00 9.00 1 ptp4l</div><div><br></div><div>I also measured the syscalls:<br>% time seconds usecs/call calls errors syscall<br>------ ----------- ----------- --------- --------- ----------------<br>93.93 8.250598 10073 819 clock_adjtime<br> 3.16 0.277860 206 1345 ppoll<br> 1.56 0.137313 70 1944 recvmsg<br> 0.64 0.055852 140 397 sendto<br> 0.56 0.049168 53 921 timerfd_settime<br> 0.15 0.013388 69 193 recvfrom<br>------ ----------- ----------- --------- --------- ----------------<br>100.00 8.784179 5619 total</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does it always take much less than 10ms, or is that usually so.<br>
If it is the former, then do we need to wait for in the order of<br>
10000 x 5us = 50ms before giving up?</blockquote><div><br></div><div>Considering 8 sync messages per second, I have observed that around 85% of "config_addend" calls takes more than 10 milliseconds to complete. I have measured that by simply using the ktime API. When I completely deleted the delay from the while loop, I saw that it took a maximum of 1.6 microseconds to finish the addend update. I decided to just change the delay to 5 microseconds, as in my opinion a 10 millisecond of a busy-loop is a overkill. The same measurements with lower delay:</div><div><br></div><div>01:01:13 UID PID %usr %system %guest %wait %CPU CPU Command<br>01:01:14 1072 710 0.00 1.00 0.00 0.00 1.00 0 ptp4l<br>01:01:15 1072 710 0.00 0.00 0.00 0.00 0.00 1 ptp4l<br>01:01:16 1072 710 0.00 1.00 0.00 0.00 1.00 0 ptp4l<br>01:01:17 1072 710 0.00 1.00 0.00 0.00 1.00 0 ptp4l<br>01:01:18 1072 710 0.00 1.00 0.00 0.00 1.00 0 ptp4l<br>01:01:19 1072 710 0.00 1.00 0.00 0.00 1.00 1 ptp4l<br>01:01:20 1072 710 0.00 1.00 0.00 0.00 1.00 1 ptp4l<br>01:01:21 1072 710 0.00 1.00 0.00 1.00 1.00 0 ptp4l<br>01:01:22 1072 710 0.00 0.00 0.00 0.00 0.00 0 ptp4l<br>01:01:23 1072 710 1.00 0.00 0.00 0.00 1.00 1 ptp4l<br>01:01:24 1072 710 0.00 1.00 0.00 0.00 1.00 1 ptp4l</div><div><br></div><div>% time seconds usecs/call calls errors syscall<br>------ ----------- ----------- --------- --------- ----------------<br> 49.12 0.161379 191 843 ppoll<br> 22.41 0.073623 62 1184 recvmsg<br> 9.31 0.030585 125 244 sendto<br> 8.71 0.028625 57 499 clock_adjtime<br> 8.33 0.027364 48 561 timerfd_settime<br> 2.13 0.006996 58 119 recvfrom<br>------ ----------- ----------- --------- --------- ----------------<br>100.00 0.328572 3450 total</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would actually suggest rewriting this using the macros from iopoll.h.</blockquote><div><br></div><div>I will try rewriting it using macros from iopoll.h</div><div><br></div><div>Thanks,<br></div><div>Bartlomiej Dziag</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">sob., 7 cze 2025 o 18:21 Simon Horman <<a href="mailto:horms@kernel.org">horms@kernel.org</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jun 06, 2025 at 12:19:49PM +0200, Bartlomiej Dziag wrote:<br>
> After writing a new value to the PTP_TAR or PTP_STSUR registers,<br>
> the driver waits for the addend/adjust operations to complete.<br>
> Sometimes, the first check operation fails, resulting in<br>
> a 10 milliseconds busy-loop before performing the next check.<br>
> Since updating the registers takes much less than 10 milliseconds,<br>
> the kernel gets stuck unnecessarily. This may increase the CPU usage.<br>
> Fix that with changing the busy-loop interval to 5 microseconds.<br>
> The registers will be checked more often.<br>
<br>
Hi Bartlomiej,<br>
<br>
I am curious.<br>
<br>
Does it always take much less than 10ms, or is that usually so.<br>
If it is the former, then do we need to wait for in the order of<br>
10000 x 5us = 50ms before giving up?<br>
<br>
> <br>
> Signed-off-by: Bartlomiej Dziag <<a href="mailto:bartlomiejdziag@gmail.com" target="_blank">bartlomiejdziag@gmail.com</a>><br>
<br>
...<br>
</blockquote></div>