Stupid question regarding bogomips and udelay()

[Daniel.]

I *guess* that the value is calculated at boot, in real mode (for x86)
when no clock variation takes place. Take a look at the source... :)

http://lxr.free-electrons.com/source/arch/x86/realmode/rm/wakemain.c?v=4.0#L4

It brings me to some io magic which I can't grasp :) good luck!

Regards,

2016-08-02 5:27 GMT-03:00 Aleksander Alekseev <afiskon at devzen.ru>:
>> Makes sense. Do you have such machine? Did you try to get bogomips
>> and then reduce your CPU count / speed and get that number again?
>>
>> Maybe this value is now dynamic.
>
> Doesn't look like this. On my laptop CPU frequency changes all the time
> by "powersafe" governor, but bogomips doesn't change:
>
> $ cpufreq-info | grep 'current CPU frequency'
>   current CPU frequency is 2.30 GHz.
>   current CPU frequency is 2.09 GHz.
>   current CPU frequency is 2.30 GHz.
>   current CPU frequency is 1.78 GHz.
>   current CPU frequency is 2.30 GHz.
>   current CPU frequency is 2.14 GHz.
>   current CPU frequency is 2.30 GHz.
>   current CPU frequency is 2.30 GHz.
>
> $ cat /proc/cpuinfo | grep bogomips
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
> bogomips        : 4589.79
>
> It should also be noted that 4 of 8 cores are in fact not real, Hyper
> Threading cores. In best case they execute like 10% of a real core time.
>
>> Also, did you actually try udealay() in high/low frequency to see
>> wether you see an actual difference between runs?
>
> I'm afraid I didn't write a single LKM so far. Sounds like a good idea
> for the first one though. However I wonder how exactly should I measure
> this difference? IIRC absolute time is measured by kernel in tens of
> _milli_seconds [1]. So to get accurate results I should block a kernel
> with udelay() for hundreds of millisends at least.
>
> Is it even save? And can I really do this without affecting measurement
> results? Let's say interrupt handler will be disabled somehow for this
> time. In this case time couldn't be measured. Otherwise udelay() will
> be interrupted many times. I doubt we can call measurement results
> accurate in this case.
>
> As I understand an experiment should be like this:
>
> 1. set cpu frequencies to X
> 2. x <- current jiffies value
> 3. udelay for say 1 second
> 4. y <- current jiffies value
> 5. calculate delta1 = y - x
> 6. set cpu frequencies to X / 2
> 7. delta2 = { repeat steps 2-5 }
> 8. compare delta1 and delta2
> 9. repeat 1-8 N times just in case
>
> In theory, if udelay() really guarantees something, delta1 and delta2
> sould be approximately equal. Otherwise delta1 and delta2 should always
> differ significantly. It also makes sense to cross-check set of
> delta1's values to make sure that HT doesn't affect it (or does it?).
>
> Does all this sounds reasonable?
>
> [1] http://www.makelinux.net/books/lkd2/ch10lev1sec2
>
> --
> Best regards,
> Aleksander Alekseev
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
"Do or do not. There is no try"
  Yoda Master