From nobody Mon Oct 11 09:31:29 2021 X-Original-To: freebsd-hackers@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 2058317FDDD9 for ; Mon, 11 Oct 2021 09:31:32 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 4HSYTJ06KLz3kSq for ; Mon, 11 Oct 2021 09:31:32 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mZrec-000ESi-D2; Mon, 11 Oct 2021 11:31:30 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZrec-000Cx6-AK; Mon, 11 Oct 2021 11:31:30 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 09705480073; Mon, 11 Oct 2021 11:31:30 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 5ssTeo40jPco; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ACBF7480074; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R3KRQW76XwJW; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 77D4B480073; Mon, 11 Oct 2021 11:31:29 +0200 (CEST) Subject: Re: Large timecounter delta handling To: Konstantin Belousov Cc: FreeBSD Hackers References: <5318327d-d247-bb73-81d9-967c4ae18d32@embedded-brains.de> From: Sebastian Huber Message-ID: <994a76c2-4ea6-bfdc-bbe5-0795cf8fd4ee@embedded-brains.de> Date: Mon, 11 Oct 2021 11:31:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@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: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26319/Mon Oct 11 10:18:47 2021) X-Rspamd-Queue-Id: 4HSYTJ06KLz3kSq 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 11/10/2021 10:58, Konstantin Belousov wrote: > On Mon, Oct 11, 2021 at 09:53:31AM +0200, Sebastian Huber wrote: >> Hello, >> >> I synchronize currently the port of the FreeBSD timecounters to RTEMS.= I >> have to write test cases for all code we use in RTEMS. In 2020 some co= de was >> added to fix integer overflow issues with large time deltas while gett= ing >> the time from a timehand. >> >> https://github.com/freebsd/freebsd-src/commit/6cf2362e2c7e9061611f93a4= 8ec654a5b7451d6b#diff-8b8e2f8e41e6a847f14ab08c7d50454c20a4a135f2c2241d916= 87c0832c1d99e >> >> If a time delta obtained by tc_delta(th) is greater than or equal to >> th->th_large_delta, then some extra calculation is carried out. >> >> The th->th_large_delta is computed like this >> >> scale =3D (uint64_t)1 << 63; >> scale +=3D (th->th_adjustment / 1024) * 2199; >> scale /=3D th->th_counter->tc_frequency; >> th->th_scale =3D scale * 2; >> th->th_large_delta =3D MIN(((uint64_t)1 << 63) / scale, UINT_MAX); >> >> If we ignore the th->th_adjustment (=3D=3D 0), then we have ideally >> >> scale =3D 2**64 / f >> th->th_large_delta =3D MIN( f / 2, UINT_MAX ) >> >> Does this mean that we only need the large delta processing if a timeh= and >> was not updated for about 0.5s? >=20 > I do not understand your question. We need large_delta to handle overf= lows > in bintime_off(). tc_large_delta is computed in advance during windup = to > avoid this calculation in time reading code. Yes, I also ask since we never got bug reports for RTEMS related to such=20 a scenario. No updates for about 0.5s would mean that an RTEMS=20 application is already in a completely undefined system state. Maybe it=20 can happen in FreeBSD systems under transient overload conditions. It could happen in RTEMS, if we have an extremely long boot time, since=20 during boot interrupts are disabled. >=20 > Your question is more like "under which conditions we switch to use > tc_large_delta path in bintime_off()?" Then it is mostly right, that > long intervals between tc_windup() calls would trigger it, and it seems > that indeed it is around 0.5 sec. Yes, this was the question. I think the initialization value should be 50000: diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 81d373b3b1d0..a4792e31abd4 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -87,7 +87,7 @@ static struct timehands ths[16] =3D { [0] =3D { .th_counter =3D &dummy_timecounter, .th_scale =3D (uint64_t)-1 / 1000000, - .th_large_delta =3D 1000000, + .th_large_delta =3D 500000, .th_offset =3D { .sec =3D 1 }, .th_generation =3D 1, }, >=20 > If you have a controlled environment, just skip some tc_windup() calls > to see. Yes, I can also use a software timecounter for these tests. --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/