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@xxxxxxxxx>: >> 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@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- "Do or do not. There is no try" Yoda Master _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
