From: george anzinger <george@mvista.com>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
Joel.Becker@oracle.com, "Martin J. Bligh" <mbligh@aracnet.com>,
wim.coekaerts@oracle.com
Subject: Re: [RFC][PATCH] linux-2.5.64_monotonic-clock_A1
Date: Tue, 11 Mar 2003 14:39:56 -0800 [thread overview]
Message-ID: <3E6E65BC.2060200@mvista.com> (raw)
In-Reply-To: <1047419933.16615.704.camel@w-jstultz2.beaverton.ibm.com>
john stultz wrote:
> On Tue, 2003-03-11 at 13:47, george anzinger wrote:
>
>>Some comments below on the scaling.
>
>
> Thanks, I'll try to digest your comments and get back to you.
>
>
>
>>On a related note, I would like to extend the CLOCK_MONOTONIC code to
>>the same res as CLOCK_REALTIME in the POSIX clocks and timers patch.
>>The patch uses jiffies_64 for CLOCK_MONOTONIC, so what I would like to
>>do is use get_offset() to fill in the sub_jiffies part. Is this
>>function available (i.e. timer->get_offset()) on all archs?
>
>
>
> Nope, the timer_opts structure is i386 only. Further, the need for the
> monotonic_clock() interface is because timer->get_offset() only returns
> 32bits of information, which on a 2Ghz cpu is only ~2 seconds worth of
> time. We need multiple minutes worth of time to be returned, thus the 64
> bit return of monotonic_clock.
>
> I considered making get_offset() return a 64bit value, but worried that
> the cost of the 64bit math would hurt gettimeofday too much to be worth
> it. So rather then complicate a heavily used function to handle a very
> rare case, we decided to implement a new interface that doesn't need to
> be as fast as gettimeofday, but can handle long periods of time w/o
> interrupts.
>
>
>
>>It seems to me that the lost jiffies should be rolled into
>>get_offset(). Have you considered doing this?
>
>
> I'm not sure I'm following this? get_offset returns the amount of time
> since mark_offset() was called(last interrupt). The lost-jiffies
> compensation code I added uses get_offset() to detect how many jiffies
> should have passed. How do you suggest rolling it into get_offset?
I must have confused you. I am woking on a get time of day sort of
thing. In time.c, the gettimeofday code calls get_offset() and then
adds in lost ticks (ticks clocked by the PIT interrupt but not yet
rolled into the wall clock (xtime). I was thinking that get_offset
might be defined to add this its result.
But, back to the problem I am trying to solve. The posixtimers code
is in the common kernel and needs the result returned by get_offset
OR, we could define a new function, get_monotonictimeofday(), which
returns the jiffies since boot + get_offset() + pending ticks (i.e. it
would be the same as gettimeofday except it would use jiffies_64
instead of xtime to get its result. The format would be a timespec,
i.e. the same as xtime.
This translates directly into a system call and is also used in the
timers code to convert from wall clock time to jiffies time for timers.
Either way, we have a bit of a mess due to the arch dependency. I
don't really care which way it goes, but I do think it should be
resolved in 2.5.
thanks
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
next prev parent reply other threads:[~2003-03-11 22:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-11 19:39 [RFC][PATCH] linux-2.5.64_monotonic-clock_A1 john stultz
2003-03-11 19:40 ` john stultz
2003-03-11 21:47 ` george anzinger
2003-03-11 21:58 ` john stultz
2003-03-11 22:39 ` george anzinger [this message]
2003-03-11 22:59 ` john stultz
2003-03-11 23:44 ` george anzinger
-- strict thread matches above, loose matches on Subject: below --
2003-03-12 2:57 Jim Houston
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=3E6E65BC.2060200@mvista.com \
--to=george@mvista.com \
--cc=Joel.Becker@oracle.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=wim.coekaerts@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.