On 2/5/15 11:00 AM, Peter Wemm wrote: > On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote: >> On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote: >>> On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote: >>>> On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote: >>> ... >>> >>>>>>> It is fixed (in the proper meaning of the word, not like worked >>>>>>> around, >>>>>>> covered by paper) by the patch at the end of the mail. >>>>>>> >>>>>>> We already have a story trying to enable much less ambitious >>>>>>> option >>>>>>> -fno-strict-overflow, see r259045 and the revert in r259422. I do >>>>>>> not >>>>>>> see other way than try one more time. Too many places in kernel >>>>>>> depend on the correctly wrapping 2-complement arithmetic, among >>>>>>> others >>>>>>> are callweel and scheduler. >>>>> >>>>> Rather than depending on a compiler option, wouldn't it be better/more >>>>> robust to change ticks to unsigned, which has specified wrapping >>>>> behavior? >>>> >>>> Yes, but non-trivial. It's also not limited to ticks. Since the >>>> compiler >>>> knows when it would apply these optimizations, it would be nice if it >>>> could >>>> warn instead (GCC apparently has a warning, but clang does not). Having >>>> people do a manual audit of every signed integer expression in the tree >>>> will take a long time. >>> >>> I think I misunderstood the problem as being limited to ticks, >>> which is probably only one symptom of a fundamental change in behaviour >>> of the compiler. >>> Still, it might be worthwhile start looking at ints that ought to be >>> implemented as u_int >> >> I actually agree, I just think we are stuck with -fwrapv in the interval, >> but it's probably not a short interval. I think converting ticks to >> unsigned would be a good first start. > > For the record, I agree. However, I suspect that attempts to do so will have > a non trivial number of bugs introduced. We have a track record of recurring > problems with tcp sequence number space arithmetic and tcp timing, partly > because the wraparounds happens infrequently. > > In the mean time, I feel that telling the compiler that it's OK to let it > behave the way we expect (vs actively sabotaging it) is a viable stopgap. > Seems like it would make sense to move these functions into files that can be easily compiled outside of kernel and then adding unit tests. I've done this before, to prove that larger pcb hashes help performance on large workloads. -AlfredReceived on Thu Feb 05 2015 - 19:46:30 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC