From owner-freebsd-current@freebsd.org Sun Mar 7 22:59:34 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 E22BF55249C for ; Sun, 7 Mar 2021 22:59:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-24.consmr.mail.ne1.yahoo.com (sonic312-24.consmr.mail.ne1.yahoo.com [66.163.191.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DtxkF6V7cz4kXl for ; Sun, 7 Mar 2021 22:59:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1615157971; bh=DIinTRz06ipt468PIPgYeA4F7Vh5yaCNy8Yasv/fZ1v=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=XOOPqrmW0ElLs7xnElk5pm4YDNPhLyRD9QO7cH3ELlrr0CL6nF8xYAmjUl3usWYW/p0t8P+aADy/Ul5WYwYht1SQqDLu567U8NjpxE1+HjX4nilIgD6uanfNoCs2wYOKUUO3jTvUV2g8xegfh0z3z36Us7/q+fEFIW436B8j11gRp3Ey92XLvb5XwTmjKexvPYtyOqJ//BVIvA8gSqKg2wvgbiGCGVF4NCCFtQwwIbK1CS5gwnM8rcNNwBA3NlAmx1iKLMLC8B/7adgmaqHbFoxr9n+hg03apHSfEYEHzF9UXyGMtGpQ8kPijHctwOz1vNTvyJkGZaxLDnGIb6F/Pw== X-YMail-OSG: dYBo8dUVM1llVGwCAgBI2Z8WN.t6VZDlNxKFtt1jZRV542B11naLq4z9g49VYOd kTDRDnxGS39ufLTO5S6B7Yccv9nI4WSpjlYVjGnvm3XAAmsANOiaUNPf3VaJJLTNfU4EV1uA7iyH v6.he9PRzWb.b0joUCtMjiz9xzjpB8TcQkhdkJKyjkad3sayVh0Phd1dGhxjhdXyiGzkeOGGpkVv lwVeelrt9t4_Kz.bcqE1v6EcCmQ6irsJ6pHJ0h9kZP9qkWnAaMekscnuk2T4DV0dmro8W75qvRkg AYdqC6j8drgA5fH9hJEya_F4Mwu8imLYnrIy.ohOqf8UHwuO0Urw0shoH9T83dcrQzHEJwLq9qTX yhdwpK.MLVGqHaGPwqVG1bT8oLybh5NegtzydO_fvpU6HWTc8ea8I4hWKqFZYhN8Z75Nflsqjay_ Eoyl6vxJJF81VQbkzLrnpP5GZeOSnHeBV0Y1ClSV5NkbB267JA9L_HyeWkS6K7hEvQ82JyHGKgEp RyVbk.CC9.Fq3gi2DK7frDIHBLgjrGIH_a3ONtpE2F3LCUojS_CbiUtqQkosxn2nM0FQd6uaxsSI A4Ti5e7iUa3tWRxbLs9sY_9hFq67gOYCc.6cW9jOiWBEIWu8.MSQG8fG8pawt31gfx0amBx2sghy qAG5rXIffM45SFeyl4Oc1NqGnd331EwmZmdo6bKmZ2w1uDuKdzEHeqx3.616iHpmYn5eScJyxU9O BAP1fMuPuUs3s8Nfi7rmpIWrwYSRMZxLgpqJUt1.R1rf3QC_fc9XufwDbIx.JjNlrTXccXNn2rD9 Y9iCMhD1k7LhcmyRU8VA2BEUku9TnbH1W0rp_XiG17esSm6XljEgY1wIgU1BJ2FForS6TiVLCX8U kv.3eBHPTFgGzaHU8Ens.El5TrQR0UaCJt5vc4PtE1lU9j.jCsMARermlBr7FufbBQVDW0MD0Jfx Nh9rqLyvLVqP0mTTg89YIyz2r6m74Gb2u1_FwkiGbvNyowCz6bY07eO_AAVhjAjvR6Ej3SfUbFO3 KBchfRPo6KBTjXORKjFJo6DATiSe_Wc2sWXGdY4X2SDYENhk0dPDSnQ2EMngzQOBv2tMyrywW0c0 Bxj26hRKK1cxrf50jQOlYQmLod76aWaV6GUJUV17FFO5sWFCWtNJXdTF.mqbCPsdrTUydhT3m8t2 GnCmezL_zD1Q_iTrb3pa7h2bHfME1RaQEJKS3TKxwsQdH7TceQ87k5SEqDQJeu8.bG7vOF7lBK9y I.2TQij38hFBBzQpdPtmQo7mCNRH9g4bZCPQ33OR1iTEGXS.2N49zzj50S7DxEhN27kHnJQ8d4uk wAhAblRYCSUhVkLwic5RVx5pGRcolRMo2DsnD2q7Gx36QaQaa17Ba114LnnnG7RLaekGwVEBRZRg y8iQtYSgLG2Rza4tzYCQTn3k._La88Aq9aWcwzCzBv37Bl0sUdlV5X.VNaa0prwkUKvsKkISkssA 4G0wBMT_Mbgg4vS61Cs2S.mXH7ffDA2_h5wG86Ao8N2WzPz2bEnYXR1j1oVBKfroUFo0OCmUf0WJ RCjbLPMEmncTVIRppkD4V8MbsmiInPZG4zEfB49sRIvGiXd_.sRVe993oAsQGx7iIbPreCzi.Zqy v5PddL10pTiOr7XfyzSQAuNhpjXVIEXnhfnOgZzd145vPm7f3m7.UT.XMqfL47E_UsflwDxzjftR NNKy4dJrSdWwnE7jlI0YYnPxAi2zcnrN6.kMofConZulSqy7Qw3FRyhajWSZoCp8blXKNZbU.Fw4 8uwzRQm1BWsUXMyCDKPPqynpX68gohtEwIs1S.7hUlnhN3UUH0MM57qiyz3LLk17KyBwiVMYLLPR fkttB43LrlRglF4g9WWJ1_Dh4FJIg2xIuiVGpTYaAwWaW9BTOAD3EpVVVeTFvzxFCFTFR066HlPx 4TGenRqL4oWA2M0Cyy4DNHGt92x.fWFc8.jK1FdNb0evZiV2Pac5tujVPf_6PNYfmS7IdA0ynr67 TjY58N62tuQnfrHTtAKppiDagIHRSm93nlBDLqfa.y9CqQqF_aHkUvW9L9xGN_b4MKJFhyQwFFy6 ODCTlT.9j56jghjlG8IGkdqr9OpIU.3Tt32K0kcnXeIzvu.OkTuyhr7lsBYEqV3leSVx66zQgoq_ aIsEuqcsDpnRrP6LNfGIVkCaldxYEsYrQf8z6_TpjN2fETJ0b6VSnmyxVcPHXoFb9Qp4Ct1PumAK Va9iTdY51G.3tx7fbk9TefB7DdeIMuJeVTbc.xvO2q56kRRg5HA.YniRoF7RWrqVg1bM_8k8sB6H DiFH4aEw8JmVRszNSTzQkTGI_TvyDQckSzojbD6Xu2fCT8ORPj91OEQM.o3qZftcUoygAshAWxkf qP3X1NMehGa3iUGh2H2sSVPiUsy89cyAERdVsWBFdP1KpaH8eo_b0ZHQkEAXKuuUPWg7Ex7gJDQf FPfYvgnilWbG7N85Y016Gh87RAIi1YS7G0CzlC6ExedU- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Mar 2021 22:59:31 +0000 Received: by kubenode542.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 158d524762dfc709969d99b85168ef5a; Sun, 07 Mar 2021 22:59:29 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Waiting for bufdaemon Date: Sun, 7 Mar 2021 14:59:27 -0800 References: To: yasu@utahime.org, freebsd-current In-Reply-To: Message-Id: <54E0DAB6-FE34-4BE9-97EA-DFA1F6C2244D@yahoo.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DtxkF6V7cz4kXl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.191.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[66.163.191.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.191.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.191.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] 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: Sun, 07 Mar 2021 22:59:34 -0000 On 2021-Mar-5, at 17:35, Mark Millard wrote: > Yasuhiro Kimura yasu at utahime.org wrote on > Fri Mar 5 23:34:59 UTC 2021 : >=20 >> From: Konstantin Belousov >> Subject: Re: Waiting for bufdaemon >> Date: Fri, 5 Mar 2021 22:43:58 +0200 >>=20 >>> 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. >>>=20 >>> For you, a simple but manual workaround, setting the timecounter to >>> ACPI (?) or might be HPET, with a loader tunable, should do it. >>=20 >> Then please let me know the name of it. >>=20 >> I have experienced same situation several time. That is, I faced a >> problem and asked for it on ML. Then I was told to try some tunable. >> So I thought there may be tunable that can be used as workaround in >> this case. But for those who isn't familiar with kernel internal, it >> it quite hard to find it without knowing its name. If all tunable = were >> listed with brief explanation in one document, then I saw it and = could >> pick up possible candidates. But actually they are documented >> separately among many man pages. So the first difficulty is to find >> man page in which possible tunable may be explained. If the problem = is >> releted to some device, it is most hopeful to check its man page. But >> in this case, even after reading the commit message, I had no idea >> which man page to check. >=20 > Its somewhat messy but there is a technique of using > the "timecounter" in kib's wording to explore: >=20 > # sysctl -a | grep -i timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) = TSC-low(1000) dummy(-1000000) > kern.timecounter.hardware: TSC-low > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 3054367693 > kern.timecounter.tc.ACPI-fast.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 43913 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 3575335307 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1696849832 > kern.timecounter.tc.TSC-low.counter: 590106679 > kern.timecounter.tc.TSC-low.mask: 4294967295 >=20 > Given the references to ACPI and HPET in kib's > wording, notable seems to be (from one of my > contexts): >=20 > kern.timecounter.choice: ACPI-fast(900) i8254(0) HPET(950) = TSC-low(1000) dummy(-1000000) > kern.timecounter.hardware: TSC-low >=20 > The descriptions of those two look like: >=20 > # sysctl -ad kern.timecounter.choice kern.timecounter.hardware > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected >=20 > The "selected" wording suggests that kern.timecounter.hardware > might be able to be assigned --and kib's wording would imply > that it can be. >=20 > Looking at the descriptions without also looking at the > values need not be clear: >=20 > # sysctl -ad | grep -i timecounter > kern.timecounter:=20 > kern.timecounter.tsc_shift: Shift to pre-apply for the maximum TSC = frequency > kern.timecounter.smp_tsc_adjust: Try to adjust TSC on APs to match BSP > kern.timecounter.smp_tsc: Indicates whether the TSC is safe to use in = SMP mode > kern.timecounter.invariant_tsc: Indicates whether the TSC is P-state = invariant > kern.timecounter.fast_gettime: Enable fast time of day > kern.timecounter.tick: Approximate number of hardclock ticks in a = millisecond > kern.timecounter.choice: Timecounter hardware detected > kern.timecounter.hardware: Timecounter hardware selected > kern.timecounter.alloweddeviation: Allowed time interval deviation in = percents > kern.timecounter.timehands_count: Count of timehands in rotation > kern.timecounter.stepwarnings: Log time steps > kern.timecounter.tc:=20 > kern.timecounter.tc.ACPI-fast: timecounter description > kern.timecounter.tc.ACPI-fast.quality: goodness of time counter > kern.timecounter.tc.ACPI-fast.frequency: timecounter frequency > kern.timecounter.tc.ACPI-fast.counter: current timecounter value > kern.timecounter.tc.ACPI-fast.mask: mask for implemented bits > kern.timecounter.tc.i8254: timecounter description > kern.timecounter.tc.i8254.quality: goodness of time counter > kern.timecounter.tc.i8254.frequency: timecounter frequency > kern.timecounter.tc.i8254.counter: current timecounter value > kern.timecounter.tc.i8254.mask: mask for implemented bits > kern.timecounter.tc.HPET: timecounter description > kern.timecounter.tc.HPET.quality: goodness of time counter > kern.timecounter.tc.HPET.frequency: timecounter frequency > kern.timecounter.tc.HPET.counter: current timecounter value > kern.timecounter.tc.HPET.mask: mask for implemented bits > kern.timecounter.tc.TSC-low: timecounter description > kern.timecounter.tc.TSC-low.quality: goodness of time counter > kern.timecounter.tc.TSC-low.frequency: timecounter frequency > kern.timecounter.tc.TSC-low.counter: current timecounter value > kern.timecounter.tc.TSC-low.mask: mask for implemented bits >=20 > Looking at both can tend to narrow things down. >=20 > Not exactly direct, but useful. It might have been > harder before having kib's wording that used > terminology (notation) involved in the use of the > systctl commands. >=20 > I'll note that in the context I'm using for this: >=20 > # sysctl -ad | wc > 11153 57922 604736 >=20 > # sysctl -a | wc > 13080 29457 449667 >=20 > So: not a trivial amount of material. >=20 Kyle Evens' message points out that I inappropriately did not cover some sysctl command line options that are useful: -T Display only variables that are settable via loader (CTLFLAG_TUN). and: -W Display only writable variables that are not statistical. = Useful for determining the set of runtime tunable sysctls. So: # sysctl -aT | grep timecounter kern.timecounter.tsc_shift: 1 kern.timecounter.smp_tsc_adjust: 0 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.alloweddeviation: 5 kern.timecounter.timehands_count: 2 # sysctl -aW | grep timecounter kern.timecounter.fast_gettime: 1 kern.timecounter.hardware: TSC-low kern.timecounter.alloweddeviation: 5 kern.timecounter.stepwarnings: 0 (kern.timecounter.choice is not settable and so is not in either list. But I do not see an option for listing read-only, non-loader-tunable variables separately.) Between the -aT output and the -aW output, it indicates that /etc/sysctl.conf is appropriate for kern.timecounter.hardware assignment but /boot/loader.conf is not: writable but not a loader tunable. For reference: # sysctl -aT | wc 768 1519 20989 # sysctl -aW | wc 1506 3130 44717 (Some may be in both lists.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)