public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: tim.bird@am.sony.com, linux-kernel@vger.kernel.org
Subject: CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft
Date: Thu, 20 May 2004 11:56:24 +0200	[thread overview]
Message-ID: <m3zn83o20n.fsf_-_@averell.firstfloor.org> (raw)
In-Reply-To: <1XHzV-5OV-9@gated-at.bofh.it> (Theodore Ts'o's message of "Thu, 20 May 2004 00:20:07 +0200")

Theodore Ts'o <tytso@mit.edu> writes:
>
> B) When CONFIG_FAST_TIMESTAMPS is enabled, the kernel SHALL provide
> the following 2 routines:
>
>       2.1 void store_timestamp(timestamp_t *t)

sched_clock() already exists and does that, although it is a bit confusingly
named. 

Or just use do_gettimeofday() which should be fast - it is used
in networking after all.

>       2.2 void timestamp_to_timeval(timestamp_t *t, struct timeval *tv) 

I don't think this API is a good idea. 

The obvious way to implement timestamp_t is just store the CPU integrated
time stamp counter into it (TSC in x86 terminology). But there are CPUs
where the TSC frequency changes when the CPU changes its core frequency
for power saving purposes.

(newer designs generally avoid this problem, but older designs often have 
it). Now to convert the TSC value you need the xtime and the TSC value
when the xtime matching the TSC value and you need to know about
all frequency changes that happened inbetween, so that you can 
compute the TSC offset. 

do_gettimeofday can handle this in a atomic matter, the CPU frequency
changes just has to resync xtime (I am not sure it does this currently,
but the API allows it at least) 

But splitting it into two functions like in your spec makes this
impossible, because you would need to keep track about all the
possible frequency changes in the timestamp_t between the store and
the timestamp_to_timeval to compute the TSC offset, which is obviously
not practical.

Anyways, the only way to avoid this problem would be to not use the
CPU TSC, but some external timer that is independent of the CPU
frequency (this is sometimes already done to work around other
problems). The problem is just that such external timers in the
southbridge are usually factor 100 and more slower than an TSC access
that can stay inside the CPU, because an access first has to cross the
slow CPU front side bus.

This would turn your fast time stamp into an extremly slow time stamp.

You would be probably better of by just using do_gettimeofday(), which
actually has a chance to use the TSC sanely and is not really that
slow usually.

BTW there are other problems on multiprocessor systems with this that
I don't want to go into.

-Andi


       reply	other threads:[~2004-05-21 23:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1WVF1-Nn-25@gated-at.bofh.it>
     [not found] ` <1WVYp-11I-5@gated-at.bofh.it>
     [not found]   ` <1WXdS-279-41@gated-at.bofh.it>
     [not found]     ` <1XiBG-2sN-37@gated-at.bofh.it>
     [not found]       ` <1XF55-3Ij-7@gated-at.bofh.it>
     [not found]         ` <1XHzV-5OV-9@gated-at.bofh.it>
2004-05-20  9:56           ` Andi Kleen [this message]
2004-05-21 21:44             ` CONFIG_SLOW_TIMESTAMPS was Re: ANNOUNCE: CE Linux Forum - Specification V1.0 draft Tim Bird
2004-05-22  7:58               ` Andi Kleen

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=m3zn83o20n.fsf_-_@averell.firstfloor.org \
    --to=ak@muc.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tim.bird@am.sony.com \
    --cc=tytso@mit.edu \
    /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