From owner-svn-src-head@FreeBSD.ORG Wed Jul 3 04:40:20 2013 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9C0A9CD8; Wed, 3 Jul 2013 04:40:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 112E51B4B; Wed, 3 Jul 2013 04:40:19 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id DF222421CCF; Wed, 3 Jul 2013 14:40:17 +1000 (EST) Date: Wed, 3 Jul 2013 14:40:17 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon Subject: Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern] In-Reply-To: <51D31724.6090807@FreeBSD.org> Message-ID: <20130703134115.C1064@besplex.bde.org> References: <201306031736.r53Hain5093431@svn.freebsd.org> <51D30463.50608@FreeBSD.org> <51D30CE8.7030803@FreeBSD.org> <51D31724.6090807@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Q6eKePKa c=1 sm=1 a=leycMhyxsNAA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=qlnHYPZ3_KkA:10 a=8pif782wAAAA:8 a=t-c6XU3XfRrDXkAxBZQA:9 a=CjuIK1q_8ugA:10 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 Cc: attilio@FreeBSD.org, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 04:40:20 -0000 On Tue, 2 Jul 2013, Andriy Gapon wrote: > on 02/07/2013 20:52 Attilio Rao said the following: >> I was just pointing out that the real bug is not in the subtraction >> itself but on the hogticks comparison. >> This is because hogticks is not an absolute measurement but it >> represents really a ticks difference. >> In my opinion we should define hogticks as an unsigned int and add a >> small comment saying that it is a differential. >> This will fix the issue. This is sort of backwards. hogticks is a small positive integer. Making it unsigned just asks for sign extension bugs when it is compared with signed values. However, the tick counters are circular counters. Making them signed asks for undefined behaviour when they overflow. > I think that my original suggestion is equivalently well if not more obvious. > This is a common knowledge: > http://en.wikipedia.org/wiki/Serial_number_arithmetic#General_Solution > > distance = (signed)( i1 - i2 ) With 2's complement and benign overflow, this is no different from 'distance = i1 - i2'. But signed counters are not wanted here. A negative distance, or equivalently with 32-bit unsigned ints, an unsigned difference of >= 0x80000000 means overflow or an initialization error. Your bug is an initialization error. BTW, -ftrapv is broken in gcc-4.2.1. It seems to have worked in gcc-3.3, but gcc-3.3 generates pessimal code for it, with a call to an extern function even for adding ints. gcc-4.2.1 still generates an declaration of the extern function, but never calls it. The declaration is unnecessary even when it is used. These bugs seem to be fixed in clang, at least on amd64. clang generates an explicit inline check for overflow and executes an unsupported instruction on overflow. The code for the check is good with -O but bad (large and slow) with -O0. These bugs are still large at the hardware level. Overflow checking is handled correctly on x86 only for floating point. In floating point, you can set or clear the mode bit for trapping on overflow, so that programs can be tested without recompiling them and without adding slow runtime checks (the hardware has to pipleline the checks well so that they have low cost). Hardware support for trapping on integer overflow keeps getting worse since programmers never check for overflow. i386 has an "into" instruction that should have been used instead of "jo foo" to check for overflow. It should have been easier for hardware to optimize than the branch. But AFAIK, "into" has never been optimized and has always been slower than the branch, so programmers never used it, so AMD removed it in 64-bit mode. Speed tests for incrementing a volatile local variable on corei7 in 32-bit mode: - -fno-trapv: 6.2 cycles (clang bug: warn about -fno-trapv being unused) - add into: 12.3 cycles (error handling is SIGBUS) - -ftrapv: 6.7 cycles (error handling is SIGILL) - mod jo to into: 7.3 cycles (error handling is SIGBUS). Bruce