On Tue, 2007-02-27 at 14:04 -0500, Mathieu Desnoyers wrote:
> 1 - I do not plan to use the rcupdate.h API, because it is oriented
> towards allowing/freeing data structures after a quiescent state. I
> don't need that. I only want to have a 64 bits data structure valid for
> reading, with atomic u
On Tue, 2007-02-27 at 14:04 -0500, Mathieu Desnoyers wrote:
> __get_nsec_offset : reads clock->cycle_last. Should be called with
> xtime_lock held. (ok so far, but see below)
>
> change_clocksource
> clock->cycle_last = now; (non atomic 64 bits update. Not protected by
> any lock ?) -> this would
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-02-27 at 11:02 -0500, Mathieu Desnoyers wrote:
> > * Daniel Walker ([EMAIL PROTECTED]) wrote:
> > > On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
> > >
> > > >
> > > > I am concerned about the automatic fallback to the PIT wh
On Tue, 2007-02-27 at 11:02 -0500, Mathieu Desnoyers wrote:
> * Daniel Walker ([EMAIL PROTECTED]) wrote:
> > On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
> >
> > >
> > > I am concerned about the automatic fallback to the PIT when no other
> > > clock source is available. A clocksou
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
>
> >
> > I am concerned about the automatic fallback to the PIT when no other
> > clock source is available. A clocksource read would be atomic when TSC
> > or HPET are available, but would f
On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
>
> I am concerned about the automatic fallback to the PIT when no other
> clock source is available. A clocksource read would be atomic when TSC
> or HPET are available, but would fall back on PIT otherwise. There
> should be some way t
On Tue, 2007-02-27 at 07:29 +0100, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The pit clocksource could be dropped pretty easy with my clocksource
> > update patches, which I'm still working on but you could easily drop
> > clock sources that aren't atomic like the pit
On Tue, 2007-02-27 at 02:38 -0500, Mathieu Desnoyers wrote:
> > > The pit clocksource could be dropped pretty easy with my clocksource
> > > update patches, which I'm still working on but you could easily drop
> > > clock sources that aren't atomic like the pit .. Also the pit is
> > > generally
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
>
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The pit clocksource could be dropped pretty easy with my clocksource
> > update patches, which I'm still working on but you could easily drop
> > clock sources that aren't atomic like the pit .. Also t
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> The pit clocksource could be dropped pretty easy with my clocksource
> update patches, which I'm still working on but you could easily drop
> clock sources that aren't atomic like the pit .. Also the pit is
> generally undesirable, so it's not going
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote:
> > If an NMI nests over the spinlock, we have a deadlock.
>
> Maybe not completely safe ...
>
> > In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on
> > x86. If is therefore
On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote:
> If an NMI nests over the spinlock, we have a deadlock.
Maybe not completely safe ...
> In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on
> x86. If is therefore not updated atomically by change_clocksource,
> timekeep
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-02-26 at 17:14 -0500, Mathieu Desnoyers wrote:
>
>
> > For kernel and user space tracing, those small jumps are very annoying :
> > it can show, in a trace, that a fork() appears on a CPU after the first
> > schedule() of the thread on the
On Mon, 2007-02-26 at 17:14 -0500, Mathieu Desnoyers wrote:
> For kernel and user space tracing, those small jumps are very annoying :
> it can show, in a trace, that a fork() appears on a CPU after the first
> schedule() of the thread on the other CPU : scheduling causality relationship
> can be
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> On Mon, 2007-02-26 at 15:53 -0500, Mathieu Desnoyers wrote:
>
> > > > /* On frequency change event */
> > > > /* In irq context */
> > > > void freq_change_cb(unsigned int new_freq)
> > > > {
> > >
> > > It's possible for the TSC to change frequencies
On Mon, 2007-02-26 at 15:53 -0500, Mathieu Desnoyers wrote:
> > > /* 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
* Daniel Walker ([EMAIL PROTECTED]) wrote:
> 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 cl
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 at
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 suppo
19 matches
Mail list logo
