Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 03/07/2013 07:40 Bruce Evans said the following: On Tue, 2 Jul 2013, Andriy Gapon wrote: distance = (signed)( i1 - i2 ) With 2's complement and benign overflow, this is no different from 'distance = i1 - i2'. Given the particular context I'd say that there is a difference. But signed counters are not wanted here. A negative distance, or equivalently with 32-bit unsigned ints, an unsigned difference of = 0x8000 means overflow or an initialization error. Your bug is an initialization error. Right. But I'd rather produce a positive (unsigned) number than a negative number when such an error happens (and is detectable). Again, I am speaking about the concrete context. -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 21:11 Andriy Gapon said the following: on 02/07/2013 20:59 Ed Maste said the following: What about just initializing td_swvoltick to ticks at td creation? I like this idea. What would be the best place(s) to do the initialization? Or, perhaps, td_swvoltick should be moved to td_startcopy-td_endcopy section? -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On Tue, Jul 2, 2013 at 6:48 PM, Andriy Gapon a...@freebsd.org wrote: on 03/06/2013 20:36 Konstantin Belousov said the following: Author: kib Date: Mon Jun 3 17:36:43 2013 New Revision: 251322 URL: http://svnweb.freebsd.org/changeset/base/251322 Log: Be more generous when donating the current thread time to the owner of the vnode lock while iterating over the free vnode list. Instead of yielding, pause for 1 tick. The change is reported to help in some virtualized environments. Kostik, I've just run into a problem where word generous does not seem to be applicable at all unless I am mistaken about how the code works. While ticks is signed it is used as an unsigned int. td_swvolticks is always derived by ticks, which again will always be used as an unisgned and then the subtractions among the 2 will be consistent. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 20:12 Attilio Rao said the following: While ticks is signed it is used as an unsigned int. td_swvolticks is always derived by ticks, which again will always be used as an unisgned and then the subtractions among the 2 will be consistent. So returning to my example where ticks == -1946084020 and td_swvoltick == 0 and (ticks - td-td_swvoltick) == -1946084020. Is this consistent in your opinion? -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On Tue, Jul 2, 2013 at 7:24 PM, Andriy Gapon a...@freebsd.org wrote: on 02/07/2013 20:12 Attilio Rao said the following: While ticks is signed it is used as an unsigned int. td_swvolticks is always derived by ticks, which again will always be used as an unisgned and then the subtractions among the 2 will be consistent. So returning to my example where ticks == -1946084020 and td_swvoltick == 0 and (ticks - td-td_swvoltick) == -1946084020. Is this consistent in your opinion? 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. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
On 2 July 2013 12:48, Andriy Gapon a...@freebsd.org wrote: I am not sure if the originally reported problem was also caused by should_yield() or if it was something else. But in either case I think that we should fix should_yield. Perhaps (ticks - curthread-td_swvoltick) should be cast to unsigned before comparison? What about just initializing td_swvoltick to ticks at td creation? ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
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. 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 ) -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
on 02/07/2013 20:59 Ed Maste said the following: On 2 July 2013 12:48, Andriy Gapon a...@freebsd.org wrote: I am not sure if the originally reported problem was also caused by should_yield() or if it was something else. But in either case I think that we should fix should_yield. Perhaps (ticks - curthread-td_swvoltick) should be cast to unsigned before comparison? What about just initializing td_swvoltick to ticks at td creation? I like this idea. Still I think that distance between two wrapping numbers should be calculated properly even if that mostly would not matter in practice. distance = (signed)( i1 - i2 ) -- Andriy Gapon ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: should_yield problem [Was: svn commit: r251322 - head/sys/kern]
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 = 0x8000 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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
