On 02/04/20(Thu) 12:58, Martin wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, March 31, 2020 3:27 PM, Martin Pieuchot <[email protected]> wrote:
>
> > On 31/03/20(Tue) 15:08, Martin wrote:
> >
> > > 1. top -SH -s .3 points me that stutters arrive once process changing
> > > its state from 'idle' to 'active' with related disk activity.
> >
> > What about %spin and %intr?
>
> 1. AMD GX-420CA SOC 4-core 4-thread
>
> CPU0 %spin from 2.0% to 17.0% %intr 30.0%-96.0%
> CPU1-3 %spin 0.0% (always) %intr 15.0%-99.0%
>
> 2. i7-2640m 2-core 4-thread
>
> CPU0 %spin from 0.0% to 3.0% %intr 0.0% (always)
> CPU2 %spin from 0.0% to 2.0% (rare) %intr 0.0% (always)
Interesting so whatever that is it seems related or amplified by a lot
of time spent dealing with interrupt.
You can use "systat -s .3" and/or "vmstat -i" to figure out which
interrupt has a higher rate when you observe the symptoms.
If nobody has a idea of what that could be, another useful information
would be to produce a flamegraph when you observe the stutters. For that
you need to enable dt(4) in conf/GENERIC build & install a new kernel,
build & install btrace(8) and set kern.allowdt=1 in /etc/sysctl.conf.
After rebooting in the new kernel run the following:
# btrace -e 'profile:hz:15 { printf("%s1\n", kstack); }' > kstack.txt
and it Ctrl+C to stop the profiling.
Then you can build the Flamegraph with the tools described below or
provide us the captured stack traces:
https://github.com/brendangregg/FlameGraph
