division-by-zero about mhz

[wtarreau]

Hi Geert!
When you're saying "large clock granularity", what's the approx granularity you've been facing ? For example I remember a long time ago using HZ=100 and jiffies as the only clock source, and seeing tcpdump traces with a 10ms resolution which was not fun. But by then I hadn't developed the mhz tool and I haven't thought about this.

[geertu]

When you're saying "large clock granularity", what's the approx granularity you've been facing ? For example I remember a long time ago using HZ=100 and jiffies as the only clock source, and seeing tcpdump traces with a 10ms resolution which was not fun. But by then I hadn't developed the mhz tool and I haven't thought about this.

Using jiffies as the only clocksource, and CONFIG_HZ=100.

[wtarreau]

@geertu I can't reproduce it. In the worst case all I'm getting are lines like this:
count=10000 us50=0 us250=0 diff=0 cpu_MHz=inf
And indeed the divide is performed on a double here. I'm seeing only two integer divides:

• the first one in run_once(), divides by count, which is not supposed to be zero there (and if I forcefully pass zero the test never finishes)
• the second one in calibrate(), divides by duration, but it's done after a loop that loops for as long as duration is < 100000
  Hence I don't see how we can divide by zero there. And it doesn't seem either we could be in a case of -MAXINT/-1

Thus I'm a bit confused regarding this one for now. Any hint would be much appreciated.

[geertu]

Sorry, in userspace you indeed don't get an exception, but just an "inf" results. Which is still not what you want.

With my in-kernel version (which does an integer division), it does crash.

[wtarreau]

Ah OK it makes sense then.

Then I think it should be sufficient to loop around the test, multiplying "count" by 10 until duration is not zero. I'll give that a try.