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.
-Alfred
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
