From owner-freebsd-current@freebsd.org Thu Mar 25 15:31:30 2021 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 276D65C191C for ; Thu, 25 Mar 2021 15:31:30 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F5pwx3hlmz3lY0 for ; Thu, 25 Mar 2021 15:31:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 195.64.148.76 Received: from [192.168.0.88] (unknown [195.64.148.76]) (Authenticated sender: andriy.gapon@uabsd.com) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 7CAFFFF804; Thu, 25 Mar 2021 15:31:25 +0000 (UTC) Subject: Re: freebsd 13 ryzen micro stutter To: "Nils B." , freebsd-current@freebsd.org, freebsd@grem.de, monochrome@twcny.rr.com References: <20210323101146.18c9a969@bsd64.grem.de> <711646dd-1ff7-32e9-f3da-0add1565519a@renzel.net> From: Andriy Gapon Message-ID: <4efc1460-4460-6876-5a93-ea80c5866fa2@FreeBSD.org> Date: Thu, 25 Mar 2021 17:31:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <711646dd-1ff7-32e9-f3da-0add1565519a@renzel.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4F5pwx3hlmz3lY0 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; local_wl_from(0.00)[FreeBSD.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 15:31:30 -0000 On 23/03/2021 16:54, Nils B. wrote: > Hi, > > On 23.03.21 10:34, myfreeweb wrote: >> None of these should be an issue, but: >> >> sysctl kern.sched.steal_thresh=1 >> >> For some reason with the default value of 2, I'm seeing weird stuttering in >> youtube >> videos, games, etc. on a 5950X system. 1 (or 0, IIRC) works fine. > > yes, finally... Using a Ryzen 1700, Asrock AB350 Pro4 and Radeon RX460 and got that > awful micro stuttering all the time; not only under FreeBSD 13.0-ALPHA3 now, but > also > under FreeBSD 12-STABLE in the past. > > Occurences were during listening to music using MPV (one-second-*krk*-loops); > watching > YouTube videos (video hangs for a second but audio continues) and often simply > during > mouse movements where even MouseKeyPress- and MouseKeyRelease-events just didn't > reach > the system at all. > > Setting > >     kern.sched.steal_thresh=0 > > eliminates these micro stutterings in the whole system. > > > I also would really, really like to know the reason why this parameter has such an > impact... It's been a long time since I looked at that corner of the code. I think that in theory there should not be any difference between steal_thresh of zero, one and two. For a thread to be stolen there should be at least one thread that's runnable, but not running. That also should imply that there is a a thread that's currently running. So, values equal or less than two should mean the same thing. The only practical difference I can think of is a situation where a processor has a runnable thread but does not "realize" it, so the processor stays idle when it actually has work to do. If such a thread is not stolen then it may take some time for the processor to actually start running it. If it's stolen then the thread may start executing sooner on a different processor that was about to become idle. That's just a hypothesis though. If it's correct, then there can be a number of explanations. From a problem with inter-processor communication (e.g., related to mwait) to a slow wakeup of a core from a deep idle state to a problem with interrupt delivery. There are some tools in tools/sched/ directory. schedgraph.py can be used for visual inspection of scheduling traces collected using KTR. The file has instructions on how to collect them. Alternatively, schedgraph.d can be used to collect such traces. If anyone affected can gather a short sample that captures the problem, then there might be someone who would be willing to look at them. -- Andriy Gapon