Stupid question regarding bogomips and udelay()

Stupid question regarding bogomips and udelay()

[Aleksander Alekseev]

Hello

Currently I'm reading Linux Kernel Development, 3rd Edition by Robert
Love. Chapter 11 describes timers and udelay() procedure in
particular. According to the book (if I didn't get anything wrong):

* bogomips value (see `cat /proc/cpuinfo`) is determined only once
  during system boot
* udelay() is implemented as busy loop where number of loops is
  calculated based on bogomips value [1][2]
* udelay() guarantees that delay will be _at_least_ given number of
  usecs

It's my understanding that it shouldn't work. CPU frequency actually
changes manually (see cpufrequtils) and/or automatically depending for
instance on laptop's current battery charge. There is also such a nasty
thing as Intel Turbo Boost. In other words actual MIPS could be higher
or lower than measured MIPS. So udealy() can't guarantee anything.

Clearly I don't understand something. Could you please explain why
udelay() supposed to work?

[1]
https://github.com/torvalds/linux/blob/master/arch/x86/lib/delay.c#L171
[2]
https://github.com/torvalds/linux/blob/master/include/asm-generic/delay.h#L19

-- 
Best regards,
Aleksander Alekseev

Stupid question regarding bogomips and udelay()

[François]

Hello, that's an interesting question!
I'm currently reading the same book, but you've read more than me so far :)

On Mon, Aug 01, 2016 at 08:36:07AM +0300, Aleksander Alekseev wrote:
> * bogomips value (see `cat /proc/cpuinfo`) is determined only once
>   during system boot

As far as I know, I is (was?) the case.

> It's my understanding that it shouldn't work. CPU frequency actually
> changes manually (see cpufrequtils) and/or automatically depending for
> instance on laptop's current battery charge. There is also such a nasty
> thing as Intel Turbo Boost. In other words actual MIPS could be higher
> or lower than measured MIPS. So udealy() can't guarantee anything.

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.

Also, did you actually try udealay() in high/low frequency to see wether you
see an actual difference between runs?

Sorry I don't have final answers!

-- 
Fran?ois

Stupid question regarding bogomips and udelay()

[Aleksander Alekseev]

> 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

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@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