kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: afiskon@devzen.ru (Aleksander Alekseev)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Stupid question regarding bogomips and udelay()
Date: Tue, 2 Aug 2016 11:27:27 +0300	[thread overview]
Message-ID: <20160802112727.4da3e9f4@fujitsu> (raw)
In-Reply-To: <20160801094752.37wpzdxw7e3den5b@sith>

> 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

  reply	other threads:[~2016-08-02  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-01  5:36 Stupid question regarding bogomips and udelay() Aleksander Alekseev
2016-08-01  9:47 ` François
2016-08-02  8:27   ` Aleksander Alekseev [this message]
2016-08-03  1:20     ` Daniel.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160802112727.4da3e9f4@fujitsu \
    --to=afiskon@devzen.ru \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).