Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 28 Jan 2021 05:02:42 +0900 (JST)
From:      Yasuhiro Kimura <yasu@utahime.org>
To:        freebsd-current@freebsd.org
Subject:   Re: Waiting for bufdaemon
Message-ID:  <20210128.050242.1986722766748729591.yasu@utahime.org>
In-Reply-To: <20210116.040323.136067379540977557.yasu@utahime.org>
References:  <7c4da243-52ff-c5ee-3d56-1ae651286e0e@alvermark.net> <20210115.201030.1395690536446474720.yasu@utahime.org> <20210116.040323.136067379540977557.yasu@utahime.org>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Yasuhiro Kimura <yasu@utahime.org>
Subject: Re: Waiting for bufdaemon
Date: Sat, 16 Jan 2021 04:03:23 +0900 (JST)

> From: Yasuhiro Kimura <yasu@utahime.org>
> Subject: Re: Waiting for bufdaemon
> Date: Fri, 15 Jan 2021 20:10:30 +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<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@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.

---
Yasuhiro Kimura



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20210128.050242.1986722766748729591.yasu>