public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: "Yitzchak Eidus" <ieidus@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: how stable are the BogoMIPS and the udelay functions on "dynamic clock speed change cpus"
Date: 22 May 2006 13:32:34 +0200	[thread overview]
Message-ID: <p73very5m7h.fsf@verdi.suse.de> (raw)
In-Reply-To: <e7aeb7c60605190237w3a8554adof6ec7f1ba7927ba7@mail.gmail.com>

"Yitzchak Eidus" <ieidus@gmail.com> writes:

> because udelay work on the principle that it know "how much work the
> cpu can do in a time" and it work by just doing a loop of nothing, how
> stable is it when the cpu clock rate is keep changing all the time?
> does it update its loops_per_jiffy varible each time the cpu clock is change?
> or does it have another solution to this problem?
> or since before the cpu enter to this udelay function it must do some
> work like entering the systemcall and so on , the cpu clock rate is
> jump to the original?

Only on very old systems (pre ACPI APM era) does cpu frequency change without
the kernel knowing (ignoring Intel thermal throttling which is a different thing) 

When the kernel knows it fixes loops_per_jiffy and normally does the necessary
synchronization over CPUs. 

Obviously at least on multi core systems there are races with this.

Modern Intel CPUs (Yonah, Prescott) completely avoid the problem
because they have a constantly ticking TSC that is independent from
the actual clock rate. And __delay uses the TSC to measure time.

-Andi

      reply	other threads:[~2006-05-22 11:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19  9:37 how stable are the BogoMIPS and the udelay functions on "dynamic clock speed change cpus" Yitzchak Eidus
2006-05-22 11:32 ` Andi Kleen [this message]

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=p73very5m7h.fsf@verdi.suse.de \
    --to=ak@suse.de \
    --cc=ieidus@gmail.com \
    --cc=linux-kernel@vger.kernel.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