From nobody Wed Nov 10 18:43:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 392CC17EEC8C for ; Wed, 10 Nov 2021 18:44:00 +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 4HqDJv6YqFz4wp1; Wed, 10 Nov 2021 18:43:59 +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 1AAIhko3096346 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Nov 2021 20:43:49 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1AAIhko3096346 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1AAIhkHB096345; Wed, 10 Nov 2021 20:43:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 10 Nov 2021 20:43:46 +0200 From: Konstantin Belousov To: Andriy Gapon Cc: FreeBSD Current Subject: Re: thread on sleepqueue does not wake up after timeout Message-ID: References: <20191022104434.GM73312@kib.kiev.ua> <3a67f9a9-31cf-5814-4a68-8bdd6063b21e@FreeBSD.org> <20191022131633.GN73312@kib.kiev.ua> <9c131a2a-cc94-4d93-1ba8-595c0151e366@FreeBSD.org> <32fe4f76-155b-8b99-5782-4daafd4219d5@FreeBSD.org> <2c469dd8-ab15-b74e-c108-afc7b68901e0@FreeBSD.org> <2036d06b-b7ee-c3c7-733d-546bb6f07ad5@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2036d06b-b7ee-c3c7-733d-546bb6f07ad5@FreeBSD.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.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HqDJv6YqFz4wp1 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Wed, Nov 10, 2021 at 03:45:06PM +0200, Andriy Gapon wrote: > On 10/11/2021 11:30, Andriy Gapon wrote: > > On 09/11/2021 17:56, Andriy Gapon wrote: > > > So, as I was saying, when the delta is large the calculations in > > > tc_windup and bintime_off give slightly different results and that > > > can lead to a discontinuity of the time when timehands are switched. > > > > A quick follow-up. > > I think that both tc_windup and bintime_off have fundamentally correct > > calculations but with different precision.  Both seem to produce values > > slightly greater than a "true" value where the bintime fractional delta > > would be calculated as tc_delta * 2^64 / tc_frequency.  That's because > > of how th_scale is calculated. > > > > When the timecounter delta is greater than the frequency then the value > > in tc_windup is closer to the true value because it accounts for whole > > seconds precisely: a tc_frequency number of timecounter ticks is equal > > to one second. bintime_off, however, converts both whole seconds and > > fractions using th_scale.  So, its result is consistently greater when > > the delta is longer than a second. > > > > E.g., in my environment: tc_frequency = 14318180, th_scale = 1288420532460. > > For a delta of 14318180 (== tc_frequency) tc_windup calculates a one > > second advance, bt = { 1, 0 }. > > bintime_off for the same delta will produce bt = { 1, 1093027638570944 }. > > The difference is minuscule, just 59 ppm in relative terms. > > But it's 59 microseconds of "jumping back in time". > > > > I think that the precision of bintime_off is sufficient and its > > calculations are faster, so I think that it's better to use the same > > calculations in tc_windup as well.  Especially given that they are > > identical for sub-second deltas and longer deltas should be extremely > > rare. > > > > I am working on patch to implement this. > > The promised patch: https://people.freebsd.org/~avg/kern-tc-add-delta.diff The patch looks fine to me.