Quoting Konstantin Belousov <kostikbel_at_gmail.com> (from Fri, 5 Mar 2021 22:43:58 +0200): > On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: >> Dear src committers, >> >> From: Yasuhiro Kimura <yasu_at_utahime.org> >> 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 _at_ 3.00GHz (3000.09-MHz K8-class CPU) >> >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> >> >> Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT> >> >> >> Features2=0x5eda2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,RDRAND> >> >> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> >> >> AMD Features2=0x121<LAHF,ABM,Prefetch> >> >> Structured Extended >> Features=0x842421<FSGSBASE,AVX2,INVPCID,NFPUSG,RDSEED,CLFLUSHOPT> >> >> Structured Extended Features3=0x30000400<MD_CLEAR,L1DFL,ARCH_CAP> >> >> IA32_ARCH_CAPS=0x29<RDCL_NO,SKIP_L1DFL_VME,MDS_NO> >> >> 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 <kib_at_FreeBSD.org> >> > 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. Do you propose this to him as a test if this solves the issue with the intend to change the code to use a more suitable TC if VirtualBox is detected? Bye, Alexander. -- http://www.Leidinger.net Alexander_at_Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild_at_FreeBSD.org : PGP 0x8F31830F9F2772BF
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC