[Linux-stm32] [PATCH] net: stmmac: Change the busy-wait loops timing

[Bartłomiej Dziąg]

Hi Simon, Andrew,

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:

02:21:24      UID       PID    %usr %system  %guest   %wait    %CPU   CPU
 Command
02:21:25     1072      1660    0.00    8.00         0.00      1.00
 8.00       0     ptp4l
02:21:26     1072      1660    0.00    9.00         0.00      0.00
 9.00       0     ptp4l
02:21:27     1072      1660    0.00    9.90         0.00      0.99
 9.90       1     ptp4l
02:21:28     1072      1660    0.00    7.00         0.00      0.00
 7.00       1     ptp4l
02:21:29     1072      1660    0.00    9.00         0.00      0.00
 9.00       0     ptp4l
02:21:30     1072      1660    0.00    9.00         0.00      1.00
 9.00       1     ptp4l

I also measured the syscalls:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
93.93    8.250598       10073       819           clock_adjtime
  3.16    0.277860         206      1345           ppoll
  1.56    0.137313          70      1944           recvmsg
  0.64    0.055852         140       397           sendto
  0.56    0.049168          53       921           timerfd_settime
  0.15    0.013388          69       193           recvfrom
------ ----------- ----------- --------- --------- ----------------
100.00    8.784179                  5619           total

Does it always take much less than 10ms, or is that usually so.
> If it is the former, then do we need to wait for in the order of
> 10000 x 5us = 50ms before giving up?


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:

01:01:13      UID       PID    %usr %system  %guest   %wait    %CPU   CPU
 Command
01:01:14     1072       710    0.00    1.00    0.00    0.00    1.00     0
 ptp4l
01:01:15     1072       710    0.00    0.00    0.00    0.00    0.00     1
 ptp4l
01:01:16     1072       710    0.00    1.00    0.00    0.00    1.00     0
 ptp4l
01:01:17     1072       710    0.00    1.00    0.00    0.00    1.00     0
 ptp4l
01:01:18     1072       710    0.00    1.00    0.00    0.00    1.00     0
 ptp4l
01:01:19     1072       710    0.00    1.00    0.00    0.00    1.00     1
 ptp4l
01:01:20     1072       710    0.00    1.00    0.00    0.00    1.00     1
 ptp4l
01:01:21     1072       710    0.00    1.00    0.00    1.00    1.00     0
 ptp4l
01:01:22     1072       710    0.00    0.00    0.00    0.00    0.00     0
 ptp4l
01:01:23     1072       710    1.00    0.00    0.00    0.00    1.00     1
 ptp4l
01:01:24     1072       710    0.00    1.00    0.00    0.00    1.00     1
 ptp4l

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 49.12    0.161379         191       843           ppoll
 22.41    0.073623          62      1184           recvmsg
  9.31    0.030585         125       244           sendto
  8.71    0.028625          57       499           clock_adjtime
  8.33    0.027364          48       561           timerfd_settime
  2.13    0.006996          58       119           recvfrom
------ ----------- ----------- --------- --------- ----------------
100.00    0.328572                  3450           total

I would actually suggest rewriting this using the macros from iopoll.h.


I will try rewriting it using macros from iopoll.h

Thanks,
Bartlomiej Dziag

sob., 7 cze 2025 o 18:21 Simon Horman <horms at kernel.org> napisał(a):

> On Fri, Jun 06, 2025 at 12:19:49PM +0200, Bartlomiej Dziag wrote:
> > After writing a new value to the PTP_TAR or PTP_STSUR registers,
> > the driver waits for the addend/adjust operations to complete.
> > Sometimes, the first check operation fails, resulting in
> > a 10 milliseconds busy-loop before performing the next check.
> > Since updating the registers takes much less than 10 milliseconds,
> > the kernel gets stuck unnecessarily. This may increase the CPU usage.
> > Fix that with changing the busy-loop interval to 5 microseconds.
> > The registers will be checked more often.
>
> Hi Bartlomiej,
>
> I am curious.
>
> Does it always take much less than 10ms, or is that usually so.
> If it is the former, then do we need to wait for in the order of
> 10000 x 5us = 50ms before giving up?
>
> >
> > Signed-off-by: Bartlomiej Dziag <bartlomiejdziag at gmail.com>
>
> ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://st-md-mailman.stormreply.com/pipermail/linux-stm32/attachments/20250609/0eabe0fc/attachment.html>