From owner-freebsd-current@freebsd.org Fri Mar 5 20:44:08 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 362F8567256 for ; Fri, 5 Mar 2021 20:44:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Dsfpt6SX8z3jKH for ; Fri, 5 Mar 2021 20:44:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 125KhxCs071592 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 5 Mar 2021 22:44:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 125KhxCs071592 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 125KhwCo071591; Fri, 5 Mar 2021 22:43:58 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Mar 2021 22:43:58 +0200 From: Konstantin Belousov To: Yasuhiro Kimura Cc: freebsd-current@freebsd.org Subject: Re: Waiting for bufdaemon Message-ID: References: <20210115.201030.1395690536446474720.yasu@utahime.org> <20210116.040323.136067379540977557.yasu@utahime.org> <20210128.050242.1986722766748729591.yasu@utahime.org> <20210305.160311.867123118349124334.yasu@utahime.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210305.160311.867123118349124334.yasu@utahime.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4Dsfpt6SX8z3jKH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:470:d5e7:1::1:from]; R_SPF_SOFTFAIL(0.00)[~all]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2001:470:d5e7:1::1:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] 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: Fri, 05 Mar 2021 20:44:08 -0000 On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: > Dear src committers, > > From: Yasuhiro Kimura > Subject: Re: Waiting for bufdaemon > Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) > > >>> I have been experiencing same problem with my 13-CURRENT amd64 > >>> VirtualBox VM for about a month. The conditions that the problem > >>> happens are unclear and all what I can say is > >>> > >>> * It happens only after I login in the VM and do something for a > >>> while. If I boot the VM and shut it down immediately, it never > >>> happens. > >>> * When the problem happens, one or more unkillable processes seem to > >>> be left. > >> > >> CPU of my host is not AMD but Intel. According to the > >> /var/run/dmesg.boot of VM, information of CPU is as following. > >> > >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) > >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 > >> Features=0x1783fbff > >> Features2=0x5eda2203 > >> AMD Features=0x28100800 > >> AMD Features2=0x121 > >> Structured Extended Features=0x842421 > >> Structured Extended Features3=0x30000400 > >> IA32_ARCH_CAPS=0x29 > >> TSC: P-state invariant > >> > >> Just FYI. > > > > It took for a while to investigate, but according to the result of > > bisect following commit is the source of problem in my case. > > > > ---------------------------------------------------------------------- > > commit 84eaf2ccc6a > > Author: Konstantin Belousov > > Date: Mon Dec 21 19:02:31 2020 +0200 > > > > x86: stop punishing VMs with low priority for TSC timecounter > > > > I suspect that virtualization techniques improved from the time when we > > have to effectively disable TSC use in VM. For instance, it was reported > > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > > FreeBSD is groundlessly slow on AWS with some loads. > > > > Remove the check and start watching for complaints. > > > > Reviewed by: emaste, grehan > > Discussed with: cperciva > > Sponsored by: The FreeBSD Foundation > > Differential Revision: https://reviews.freebsd.org/D27629 > > ---------------------------------------------------------------------- > > > > I confirmed the problem still happens with 5c325977b11 but reverting > > above commit fixes it. > > Would someone please revert above commit from main, stable/13 and > releng/13.0? As I wrote previous mail I submitted this problem to > Bugzilla as bug 253087 and added the committer to Cc. But there is no > response for 34 days. > > I confirmed the problem still happens with 37cd6c20dbc of main and > 13.0-RC1. My belief is that this commit helps more users than it hurts. Namely, the VMWare and KVM users, which are majority, use fast timecounter, comparing to the more niche hypervisors like VirtualBox. For you, a simple but manual workaround, setting the timecounter to ACPI (?) or might be HPET, with a loader tunable, should do it.