From nobody Wed Nov 10 09:30:14 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 0188C183D921 for ; Wed, 10 Nov 2021 09:30:18 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hq0215BmGz4fRM; Wed, 10 Nov 2021 09:30:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2DA1B2FB8D; Wed, 10 Nov 2021 09:30:17 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: Konstantin Belousov Cc: FreeBSD Current 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> Subject: Re: thread on sleepqueue does not wake up after timeout Message-ID: <2c469dd8-ab15-b74e-c108-afc7b68901e0@FreeBSD.org> Date: Wed, 10 Nov 2021 11:30:14 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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. -- Andriy Gapon