From owner-freebsd-ppc@freebsd.org Thu Mar 14 21:06:08 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 14F36152E260 for ; Thu, 14 Mar 2019 21:06:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-14.consmr.mail.bf2.yahoo.com (sonic309-14.consmr.mail.bf2.yahoo.com [74.6.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A8F856D1B9 for ; Thu, 14 Mar 2019 21:06:07 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: b98A80QVM1ndr3O2RIri_T67nc11zhImn7xgJgXJsdFfSBstZLHBxUbkieqniOB sulCwsVOt9gP98cbicIbHoe7Rkm8l0EyvUaEPl95q_TxrLVFqTYN8iFBoebltuS6ST5s34.u8EuX 0w8kex.awM2djXZmfuSvD83uisryI.kZOR6oKlYjFze251hXY7FQ.KL_lslYsRuTKqbNsPHnPZlQ FoBRKenXxpk5SFSqMLeTWlOpGPZ6Oa5kRMNoleJRtX6THg0Vno4lHaHdOHgQQ.0BfglafvA6DT_A 4fY2sxv9dI7hQBB6sYc77Sj6PL4AP79kb.rnifvH4XlSZZdkhDi.61pIsv3VbT0ffYU0bYfr5gru RKgislDUBJg73CzCrF4N9libUUaEdcoMczq67wW7ldervDy6Ie2b3ULRREIlW7VyFxo3fqwS42E2 qRax6DBW_FV_xC4VCM8vYEOiQwjnw1zZjCLW3yOAO_8UlUsYSdr_iRm7SSQPoeubfmixFpETpuWb d7ffs4z2UYyF_WSIGm0LOV2DyRliXel_uErbdBfDS.0tarI_oQJU9u83xa5tiAMoaUYLFR1sVBLA R8QYRH9.c5jtTMfXwmWGmj.qQ2UvEvP7pz3NOvCNzh62mzEaLKitULMswSTYyRRTyAlufuEgajB4 QKHRajgftJLKdEoHhKCS4DHEVvvrmMONHQAau1ndn2aSdlmZuFbriIbTMiVCA5aq2vnGY_0CiR5b BtjdcZEcM6Ut0ZfztH67I_uDMuRZ6n348YVwuShHtfEv7TSzc4qi_cwdnn4hmKamx1IVE6UJEGAd xpIbRMaOynGn6VRRxzClgt8ljVcKZfezWITxugaUC8oxwVsCuE1tobBHqgFLSN1xnlXegW39TImJ sCb7yvfMzR5Cbjjc9fVP8dhb7J1.dbAacpYu9y3TDcfKspE5LIz2KnjsIvkc7YPDFPMS0212EvUc P6STZedz_U8_xbPrJ4pstaA6LGlI6gCj5NhdxDHHmamW5bqvuCOk2TEIM07bQ8eXt0x9ApJ1UDL0 5bPWHJUwyeNH80JGHZRqwgbS8YMeG4HwcgQ0ZkQ_UtHA6jiKcdlzbncT5WXl49BvS09oW51NNmKS .HWr7CA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 Mar 2019 21:06:00 +0000 Received: from c-67-170-167-181.hsd1.or.comcast.net (EHLO [192.168.1.113]) ([67.170.167.181]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9bb07e4b69e4d33f5b956231b2bf4305; Thu, 14 Mar 2019 21:06:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed] From: Mark Millard In-Reply-To: <20190314193946.GJ2492@kib.kiev.ua> Date: Thu, 14 Mar 2019 14:05:57 -0700 Cc: Bruce Evans , freebsd-hackers Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: 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> <20190314193946.GJ2492@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: A8F856D1B9 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.993,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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 21:06:08 -0000 On 2019-Mar-14, at 12:39, Konstantin Belousov = wrote: > On Thu, Mar 07, 2019 at 05:29:51PM -0800, Mark Millard wrote: >> A basic question and a small note. >>=20 >> Question's context for it tc->tc_get_timecount(tc) values:=20 >>=20 >> 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. >>=20 >> The question is . . . >>=20 >> In tc_delta's: >>=20 >> tc->tc_get_timecount(tc) - th->th_offset_count >>=20 >> 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=20 >> 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). >=20 Okay. Thanks. Just FYI: I asked because in my powerpc64 context I was seeing (in sleepq_timeout) td->td_sleeptimo > sbinuptime() in: if (td->td_sleeptimo > sbinuptime() || td->td_sleeptimo =3D=3D = 0) { /* * The thread does not want a timeout (yet). */ and without such sleeps being rescheduled in that case, those sleeps hang up. My hack to temporarily enable useful operation was to have binuptime avoid tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences, as shown below: . . . do { do { // HACK!!! th=3D timehands; tc=3D th->th_counter; gen=3D atomic_load_acq_int(&th->th_generation); tim_cnt=3D tc->tc_get_timecount(tc); tim_offset=3D th->th_offset_count; tim_wrong_order_diff=3D tim_offset-tim_cnt; } while (tim_cntth_offset; . . . where I experimentally came up with the following for the specific = PowerMac G5 context: u_int const wrong_order_diff_proper_upper_bound=3D 0x14u; // = 0x11 is max observed diff so far HACK!!! I've not hand any hung-up sleeps after that change. Despite being a = hack, this gives evidence that tc->tc_get_timecount(tc) < th->th_offset_count for small enough differences (in binuptime) is involved in the hangups in some essential way for the PowerMac G5 context. I look forward to removing this hack at some point, when things just work for this 2 socket, 2 cores per socket powerpc64 context. But for now the hack is locally useful. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)