From nobody Wed Nov 10 13:45:06 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 72B3C1855415 for ; Wed, 10 Nov 2021 13:45:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Hq5h42pJ9z3Mhr; Wed, 10 Nov 2021 13:45:08 +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 E04E53184F; Wed, 10 Nov 2021 13:45:07 +0000 (UTC) (envelope-from avg@FreeBSD.org) Subject: Re: thread on sleepqueue does not wake up after timeout 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> <2c469dd8-ab15-b74e-c108-afc7b68901e0@FreeBSD.org> Message-ID: <2036d06b-b7ee-c3c7-733d-546bb6f07ad5@FreeBSD.org> Date: Wed, 10 Nov 2021 15:45:06 +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: <2c469dd8-ab15-b74e-c108-afc7b68901e0@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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 -- Andriy Gapon