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#L... 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@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@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- "Do or do not. There is no try" Yoda Master