Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Mar 2019 17:29:51 -0800
From:      Mark Millard <marklmi@yahoo.com>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Bruce Evans <brde@optusnet.com.au>, freebsd-hackers Hackers <freebsd-hackers@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>
Subject:   Re: powerpc64 head -r344018 stuck sleeping problems: th->th_scale * tc_delta(th) overflows unsigned 64 bits sometimes [patched failed]
Message-ID:  <5EED3352-2E8C-4BEE-B281-4AC8DE9570C2@yahoo.com>
In-Reply-To: <20190307222220.GK2492@kib.kiev.ua>
References:  <20190302142521.GE68879@kib.kiev.ua> <20190303041441.V4781@besplex.bde.org> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
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)?


The note:

On 2019-Mar-7, at 14:22, Konstantin Belousov <kostikbel@gmail.com> wrote:

> . . .
> +
> +	if (__predict_false(delta < large_delta)) {

I thought that delta<large_delta was the non-overflow context
for scale*delta and that the overflow case for the multiplication
was when delta>=large_delta .

> +		/* 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)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5EED3352-2E8C-4BEE-B281-4AC8DE9570C2>