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
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
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
* 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
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
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
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
> > >
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
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 .. Also
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 to
* 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 fall back
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 clocksource read
* 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 when no other
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 race
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
* 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
* 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
* 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
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,
>
* 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
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
* 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
* 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 clock
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 the system goes
* 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 without notification.
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
* 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 other
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,
* 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 not
* 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 to
* 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 the pit is
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
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
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
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
38 matches
Mail list logo
