From owner-freebsd-ppc@freebsd.org Thu Mar 14 19:39:56 2019 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 762E2152925C; Thu, 14 Mar 2019 19:39:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B1A1C8E56D; Thu, 14 Mar 2019 19:39:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x2EJdmBX061154 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Mar 2019 21:39:51 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x2EJdmBX061154 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x2EJdkor061152; Thu, 14 Mar 2019 21:39:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Mar 2019 21:39:46 +0200 From: Konstantin Belousov To: Mark Millard Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] Message-ID: <20190314193946.GJ2492@kib.kiev.ua> References: <20190303111931.GI68879@kib.kiev.ua> <20190303223100.B3572@besplex.bde.org> <20190303161635.GJ68879@kib.kiev.ua> <20190304043416.V5640@besplex.bde.org> <20190304114150.GM68879@kib.kiev.ua> <20190305031010.I4610@besplex.bde.org> <20190306172003.GD2492@kib.kiev.ua> <20190308001005.M2756@besplex.bde.org> <20190307222220.GK2492@kib.kiev.ua> <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com> User-Agent: Mutt/1.11.3 (2019-02-01) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2019 19:39:56 -0000 On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: > A basic question and a small note. > > Question's context for it tc->tc_get_timecount(tc) values: > > In the powerpc64 context tc->tc_get_timecount(tc) is the lower > 32 bits of the tbr, in my context having a 33,333,333 MHz or so > increment rate for a machine with a 2.5 GHz or so clock rate. > The truncated 32 bit tbr value wraps every 128 seconds or so. > 2 sockets, 2 cores per socket, so 4 separate tbr values. > > The question is . . . > > In tc_delta's: > > tc->tc_get_timecount(tc) - th->th_offset_count > > is observing tc->tc_get_timecount(tc) < th->th_offset_count > ever supposed to be possible in correct operation, other than > tc->tc_get_timecount(tc) having wrapped around (and so being > newly 0 or "near" 0, no evidence of of having it having been > near 128 seconds or more for my context)? I think yes, there is no reason for current get_timecount() value to have any arithmetic relation to th_offset_count. Look at tc_windup() on how the th_offset_count is calculated. The final value is clamped by the tc_counter_mask, so only lower bits are important (higher bits are evacuated to th_offset or lost due to overflow if tc_windup() was not called soon enough). > > > The note: > > On 2019-Mar-7, at 14:22, Konstantin Belousov wrote: > > > . . . > > + > > + if (__predict_false(delta < large_delta)) { > > I thought that delta for scale*delta and that the overflow case for the multiplication > was when delta>=large_delta . You are right, I fixed this in my repo. > > > + /* Avoid overflow for scale * delta. */ > > + x = (scale >> 32) * delta; > > + bt->sec += x >> 32; > > + bintime_addx(bt, x << 32); > > + bintime_addx(bt, (scale & 0xffffffff) * delta); > > + } else { > > + bintime_addx(bt, scale * delta); > > + } > > . . . > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar)