On Thu, 2008-01-10 at 14:52 -0800, john stultz wrote:
> The issue is that the race isn't just between the readers and the
> writer, but that time races against writer as well. So if you don't lock
> the readers out during the write, I'm not sure how you can avoid the
> window for inconsistencies.
On Thu, 2008-01-10 at 17:00 -0500, Mathieu Desnoyers wrote:
> * john stultz ([EMAIL PROTECTED]) wrote:
> >
> > On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
> > > I think it's about time I introduce the approach I have taken for LTTng
> > > timestamping. Basically, one of the main
On Thu, 10 Jan 2008, Mathieu Desnoyers wrote:
>
> Am I only partially crazy ? ;)
Not at all, you should just do some more shopping!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
> > I think it's about time I introduce the approach I have taken for LTTng
> > timestamping. Basically, one of the main issues with the clock sources
> > is the xtime lock : having a read
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
> I think it's about time I introduce the approach I have taken for LTTng
> timestamping. Basically, one of the main issues with the clock sources
> is the xtime lock : having a read seqlock nested over a write seqlock is
> a really,
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
> > > Tony: ia64 also needs something like this, but I found the fsyscall asm
> > > bits a little difficult to grasp. So I'll need some assistance on how to
> > > include the accumulated cycles into
On Thu, 2008-01-10 at 15:15 -0500, Steven Rostedt wrote:
> > I'm trying to figure out all the ramifications of the new
> > "cycle_accumulated" field. Does it really need to be
>
> John,
>
> Before we hardcode these names, can we change them? Later in the series I
> use something called
On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
> > Tony: ia64 also needs something like this, but I found the fsyscall asm
> > bits a little difficult to grasp. So I'll need some assistance on how to
> > include the accumulated cycles into the final calculation.
>
> I'm trying to figure
> I'm trying to figure out all the ramifications of the new
> "cycle_accumulated" field. Does it really need to be
John,
Before we hardcode these names, can we change them? Later in the series I
use something called 'cycle_raw' which really should be called
'cycle_accumulated'. Since
> Tony: ia64 also needs something like this, but I found the fsyscall asm
> bits a little difficult to grasp. So I'll need some assistance on how to
> include the accumulated cycles into the final calculation.
I'm trying to figure out all the ramifications of the new
"cycle_accumulated" field.
Tony: ia64 also needs something like this, but I found the fsyscall asm
bits a little difficult to grasp. So I'll need some assistance on how to
include the accumulated cycles into the final calculation.
I'm trying to figure out all the ramifications of the new
cycle_accumulated field. Does
I'm trying to figure out all the ramifications of the new
cycle_accumulated field. Does it really need to be
John,
Before we hardcode these names, can we change them? Later in the series I
use something called 'cycle_raw' which really should be called
'cycle_accumulated'. Since
On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
Tony: ia64 also needs something like this, but I found the fsyscall asm
bits a little difficult to grasp. So I'll need some assistance on how to
include the accumulated cycles into the final calculation.
I'm trying to figure out all
* john stultz ([EMAIL PROTECTED]) wrote:
On Thu, 2008-01-10 at 11:54 -0800, Tony Luck wrote:
Tony: ia64 also needs something like this, but I found the fsyscall asm
bits a little difficult to grasp. So I'll need some assistance on how to
include the accumulated cycles into the final
On Thu, 2008-01-10 at 15:15 -0500, Steven Rostedt wrote:
I'm trying to figure out all the ramifications of the new
cycle_accumulated field. Does it really need to be
John,
Before we hardcode these names, can we change them? Later in the series I
use something called 'cycle_raw' which
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
I think it's about time I introduce the approach I have taken for LTTng
timestamping. Basically, one of the main issues with the clock sources
is the xtime lock : having a read seqlock nested over a write seqlock is
a really, really
* john stultz ([EMAIL PROTECTED]) wrote:
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
I think it's about time I introduce the approach I have taken for LTTng
timestamping. Basically, one of the main issues with the clock sources
is the xtime lock : having a read seqlock
On Thu, 10 Jan 2008, Mathieu Desnoyers wrote:
Am I only partially crazy ? ;)
Not at all, you should just do some more shopping!
-- Steve
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 2008-01-10 at 17:00 -0500, Mathieu Desnoyers wrote:
* john stultz ([EMAIL PROTECTED]) wrote:
On Thu, 2008-01-10 at 15:42 -0500, Mathieu Desnoyers wrote:
I think it's about time I introduce the approach I have taken for LTTng
timestamping. Basically, one of the main issues with
On Wed, 9 Jan 2008, john stultz wrote:
> > Index: linux-compile-i386.git/kernel/time/timekeeping.c
> > ===
> > --- linux-compile-i386.git.orig/kernel/time/timekeeping.c 2008-01-09
> > 14:07:34.0 -0500
> > +++
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
> plain text document attachment (rt-time-starvation-fix.patch)
> Handle accurate time even if there's a long delay between
> accumulated clock cycles.
>
> Signed-off-by: John Stultz <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt
On Wed, 9 Jan 2008, john stultz wrote:
> > ---
> > arch/x86/kernel/vsyscall_64.c |5 ++-
> > include/asm-x86/vgtod.h |2 -
> > include/linux/clocksource.h | 58
> > --
> > kernel/time/timekeeping.c | 35 +
>
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
> plain text document attachment (rt-time-starvation-fix.patch)
> Handle accurate time even if there's a long delay between
> accumulated clock cycles.
>
> Signed-off-by: John Stultz <[EMAIL PROTECTED]>
> Signed-off-by: Steven Rostedt
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/x86/kernel/vsyscall_64.c |5 ++-
include/asm-x86/vgtod.h |2 -
include/linux/clocksource.h
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
arch/x86/kernel/vsyscall_64.c |5 ++-
include/asm-x86/vgtod.h |2 -
include/linux/clocksource.h |
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
plain text document attachment (rt-time-starvation-fix.patch)
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL
On Wed, 9 Jan 2008, john stultz wrote:
---
arch/x86/kernel/vsyscall_64.c |5 ++-
include/asm-x86/vgtod.h |2 -
include/linux/clocksource.h | 58
--
kernel/time/timekeeping.c | 35 +
4 files
On Wed, 2008-01-09 at 18:29 -0500, Steven Rostedt wrote:
plain text document attachment (rt-time-starvation-fix.patch)
Handle accurate time even if there's a long delay between
accumulated clock cycles.
Signed-off-by: John Stultz [EMAIL PROTECTED]
Signed-off-by: Steven Rostedt [EMAIL
On Wed, 9 Jan 2008, john stultz wrote:
Index: linux-compile-i386.git/kernel/time/timekeeping.c
===
--- linux-compile-i386.git.orig/kernel/time/timekeeping.c 2008-01-09
14:07:34.0 -0500
+++
29 matches
Mail list logo
