Hello Martin, Have you found anything regarding the issue?
Now I have time to add dt(4) in conf/GENERIC build & install a new kernel, build & install btrace(8) and set kern.allowdt=1 in /etc/sysctl.conf. Looks like dt(4) is a part of -current, but I can't move to -current right now. I'm going to do it once 6.7 is released. Thank you. Martin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, April 3, 2020 11:06 AM, Martin Pieuchot <[email protected]> wrote: > On 03/04/20(Fri) 09:40, Martin wrote: > > > Hello, Martin. > > [...] > > When I run mpv and try to watch 720p video. In case of stutters after some > > time of watching audio flow desyncronized with video flow and mpv show > > video FPS/2 rate afterwards. > > Each time of stutter mpv increase 'Dropped' like > > A-V: 0.000 Dropped: 58++ Cahce: 1378s+154MB > > Ok so the piece of software is mpv(1). > > > I did ktrace for mpv process. I run and see by 'kdump -H ktrace.out' that > > it has > > one process ID and / mostly one-three thread used. > > But sometimes (assuming in stutter times) it jumping against treads with > > different numbers. > > Could you upload the output of kdump -H somewhere such that I could look > at it or compress it and send it? > > > Yes, IPI increased to 900-1000 when stutter appears. > > I'm going to disable step-by step each 'out of the box' software to > > determine the reason. Am I right doing this way? > > I believe it isn't necessary. From what you are saying it seems that > mpv(1) alone is the piece of software exposing the issue. > > There are multiple possible reasons for IPIs, but if the high rate > you're seeing is exposed by mpv(1), it would suggest they are related > to scheduling. > > By looking at the output of ktrace(1) we should have a better > understanding of what is happening in userland. I'd suggest you also do > the btrace(8) profiling so we can see which code path in the kernel is > responsible for the IPIs. These should allows us to work with facts and > not guesses. > > Thanks for your efforts, > Martin
