From mboxrd@z Thu Jan  1 00:00:00 1970
From: afiskon@devzen.ru (Aleksander Alekseev)
Date: Tue, 2 Aug 2016 11:27:27 +0300
Subject: Stupid question regarding bogomips and udelay()
In-Reply-To: <20160801094752.37wpzdxw7e3den5b@sith>
References: <20160801083607.02157a64@fujitsu>
	<20160801094752.37wpzdxw7e3den5b@sith>
Message-ID: <20160802112727.4da3e9f4@fujitsu>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

> 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