[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1172340369.24216.31.camel@imap.mvista.com>
Date: Sat, 24 Feb 2007 10:06:09 -0800
From: Daniel Walker <dwalker@...sta.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: mbligh@...gle.com, linux-kernel@...r.kernel.org,
johnstul@...ibm.com
Subject: Re: [RFC] Fast assurate clock readable from user space and NMI
handler
On Sat, 2007-02-24 at 11:19 -0500, Mathieu Desnoyers wrote:
> Hi,
>
> I am trying to improve the Linux kernel time source so it can be read
> without seqlock from NMI handlers. I have also seen some interest for
> such an accurate monotonic clock readable from user space. It mainly
> implies an atomic update of the time value. I am also trying to figure a
> way to support architectures with multiple CPUs with non-synchronized
> TSCs.
>
> I would like to have your comments on the following idea.
>
> Thanks in advance,
>
> Mathieu
>
>
> Monotonic accurate time
>
> The goal of this design is to provide a monotonic time :
>
> Readable from userspace without a system call
> Readable from NMI handler
> Readable without disabling interrupts
> Readable without disabling preemption
> Only one clock source (most precise available : tsc)
> Support architectures with variable TSC frequency.
I don't think you could use only the tsc. From reviewing John, and
Thomas work it's pretty clear the TSC isn't going to work correctly all
the time.
> /* On frequency change event */
> /* In irq context */
> void freq_change_cb(unsigned int new_freq)
> {
It's possible for the TSC to change frequencies without notification. It
can also completely stop when the system goes idle.
> /* Userspace */
> /* Export all this data to user space through the vsyscall page. Use a function
> * like read_time to read the walltime. This function can be implemented as-is
> * because it doesn't need to disable preemption. */
What would be the benefit of using this over the vsyscall gettimeofday()
from userspace ?
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists