On Sat, Feb 17, 2007 at 04:19:58PM +0100, Thomas Gleixner wrote:
> On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote:
> > > This is one of the reasons why we don't just use good old
> > > do_gettimeofday(), since it takes locks and can lead to lock recursion
> > > if parts of itself are probed.
On Sat, Feb 17, 2007 at 04:19:58PM +0100, Thomas Gleixner wrote:
On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote:
This is one of the reasons why we don't just use good old
do_gettimeofday(), since it takes locks and can lead to lock recursion
if parts of itself are probed.
On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote:
> > This is one of the reasons why we don't just use good old
> > do_gettimeofday(), since it takes locks and can lead to lock recursion
> > if parts of itself are probed.
>
> do_gettimeofday doesn't take locks.
>
> Only restriction is that
> This is one of the reasons why we don't just use good old
> do_gettimeofday(), since it takes locks and can lead to lock recursion
> if parts of itself are probed.
do_gettimeofday doesn't take locks.
Only restriction is that you can't single step it with long
pauses between instructions.
This is one of the reasons why we don't just use good old
do_gettimeofday(), since it takes locks and can lead to lock recursion
if parts of itself are probed.
do_gettimeofday doesn't take locks.
Only restriction is that you can't single step it with long
pauses between instructions.
-Andi
On Sat, 2007-02-17 at 15:56 +0100, Andi Kleen wrote:
This is one of the reasons why we don't just use good old
do_gettimeofday(), since it takes locks and can lead to lock recursion
if parts of itself are probed.
do_gettimeofday doesn't take locks.
Only restriction is that you can't
On Fri, Feb 16, 2007 at 02:47:45PM -0800, Daniel Walker wrote:
> > > Gets pretty ugly .. The clocksource interface already has a positive
> > > rating to describe the "best" clocks in the system, which is used to
> > > return the "best" clock .. Where the maintainers of the system give each
> > >
On Fri, 2007-02-16 at 17:10 -0500, Jeff Muizelaar wrote:
>
> I still meant for _with_features to have same semantics so calling:
>
> clocksource_get_clock_with_features(CLOCKSOURCE_PM_UNAFFECTED|CLOCKSOURCE_STABLE
> |CLOCKSOURC_ATOMIC|CLOCKSOURCE_64BITS|CLOCKSOURCE_CONTINUOUS);
>
> would be
On Fri, Feb 16, 2007 at 01:06:19PM -0800, Daniel Walker wrote:
> On Fri, 2007-02-16 at 14:34 -0500, Jeff Muizelaar wrote:
> > It think it would be better if you had sometime like
> > 'clocksource_get_clock_with_features()' that took flags describing the
> > needed characteristics instead of the
Hi -
On Fri, Feb 16, 2007 at 09:03:23PM +0100, Andi Kleen wrote:
> > We in systemtap land have the same problem, and so far made do with
> > slightly postprocessed per-cpu TSC values.
>
> 90+% likely you're not solving your problem correctly this way.
Yes, it was done as a last resort.
We need
On Fri, 2007-02-16 at 14:34 -0500, Jeff Muizelaar wrote:
> On Fri, Feb 16, 2007 at 10:28:50AM -0800, Daniel Walker wrote:
> > On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
> > > On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
> > > > I've been working on a patch set
On Fri, Feb 16, 2007 at 10:44:15AM -0800, Randy Dunlap wrote:
> On Fri, 16 Feb 2007 13:30:14 -0500 Jeff Muizelaar wrote:
>
> > On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
> > > Jeff Muizelaar <[EMAIL PROTECTED]> writes:
> > >
> > > > I've built a tool with the goal of
On Fri, Feb 16, 2007 at 09:02:44PM +0100, Andi Kleen wrote:
> Jeff Muizelaar <[EMAIL PROTECTED]> writes:
> >
> > The question is, what api should I be using? I need something that can
> > be called from inside interrupt handlers, and obviously the more
> > accurate and the lower the overhead the
On Fri, Feb 16, 2007 at 10:28:50AM -0800, Daniel Walker wrote:
> On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
> > On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
> > > I've been working on a patch set (below), to expose the clocksources
> > > used by generic time to
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
>
> We in systemtap land have the same problem, and so far made do with
> slightly postprocessed per-cpu TSC values.
90+% likely you're not solving your problem correctly this way.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe
Jeff Muizelaar <[EMAIL PROTECTED]> writes:
>
> The question is, what api should I be using? I need something that can
> be called from inside interrupt handlers, and obviously the more
> accurate and the lower the overhead the better.
Use do_gettimeofday(). sched_clock() is not for general use
On Fri, 16 Feb 2007 13:30:14 -0500 Jeff Muizelaar wrote:
> On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
> > Jeff Muizelaar <[EMAIL PROTECTED]> writes:
> >
> > > I've built a tool with the goal of logging mmio writes and reads by
> > > device drivers. See
On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
> On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
> > I've been working on a patch set (below), to expose the clocksources
> > used by generic time to multiple users . It would allow timestamps from
> > different clocks in a
On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
> Jeff Muizelaar <[EMAIL PROTECTED]> writes:
>
> > I've built a tool with the goal of logging mmio writes and reads by
> > device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
>
> FWIW, this is exactly a type of
On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
> I've been working on a patch set (below), to expose the clocksources
> used by generic time to multiple users . It would allow timestamps from
> different clocks in a generic way. It's not merged, but I'd appreciate
> any input
On Fri, 2007-02-16 at 11:30 -0500, Frank Ch. Eigler wrote:
> Jeff Muizelaar <[EMAIL PROTECTED]> writes:
>
> > I've built a tool with the goal of logging mmio writes and reads by
> > device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
>
> FWIW, this is exactly a type of add-on
Jeff Muizelaar <[EMAIL PROTECTED]> writes:
> I've built a tool with the goal of logging mmio writes and reads by
> device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
FWIW, this is exactly a type of add-on trace patch that could be
mooted by adoption of the ltt/systemtap "marker"
Jeff Muizelaar [EMAIL PROTECTED] writes:
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
FWIW, this is exactly a type of add-on trace patch that could be
mooted by adoption of the ltt/systemtap marker
On Fri, 2007-02-16 at 11:30 -0500, Frank Ch. Eigler wrote:
Jeff Muizelaar [EMAIL PROTECTED] writes:
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
FWIW, this is exactly a type of add-on trace patch
On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
I've been working on a patch set (below), to expose the clocksources
used by generic time to multiple users . It would allow timestamps from
different clocks in a generic way. It's not merged, but I'd appreciate
any input either of
On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
Jeff Muizelaar [EMAIL PROTECTED] writes:
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
FWIW, this is exactly a type of add-on trace
On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
I've been working on a patch set (below), to expose the clocksources
used by generic time to multiple users . It would allow timestamps from
different clocks in a generic
On Fri, 16 Feb 2007 13:30:14 -0500 Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
Jeff Muizelaar [EMAIL PROTECTED] writes:
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See
Jeff Muizelaar [EMAIL PROTECTED] writes:
The question is, what api should I be using? I need something that can
be called from inside interrupt handlers, and obviously the more
accurate and the lower the overhead the better.
Use do_gettimeofday(). sched_clock() is not for general use
and
[EMAIL PROTECTED] (Frank Ch. Eigler) writes:
We in systemtap land have the same problem, and so far made do with
slightly postprocessed per-cpu TSC values.
90+% likely you're not solving your problem correctly this way.
-Andi
-
To unsubscribe from this list: send the line unsubscribe
On Fri, Feb 16, 2007 at 10:28:50AM -0800, Daniel Walker wrote:
On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
I've been working on a patch set (below), to expose the clocksources
used by generic time to multiple
On Fri, Feb 16, 2007 at 09:02:44PM +0100, Andi Kleen wrote:
Jeff Muizelaar [EMAIL PROTECTED] writes:
The question is, what api should I be using? I need something that can
be called from inside interrupt handlers, and obviously the more
accurate and the lower the overhead the better.
On Fri, Feb 16, 2007 at 10:44:15AM -0800, Randy Dunlap wrote:
On Fri, 16 Feb 2007 13:30:14 -0500 Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 11:30:56AM -0500, Frank Ch. Eigler wrote:
Jeff Muizelaar [EMAIL PROTECTED] writes:
I've built a tool with the goal of logging mmio writes
On Fri, 2007-02-16 at 14:34 -0500, Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 10:28:50AM -0800, Daniel Walker wrote:
On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
I've been working on a patch set (below), to
Hi -
On Fri, Feb 16, 2007 at 09:03:23PM +0100, Andi Kleen wrote:
We in systemtap land have the same problem, and so far made do with
slightly postprocessed per-cpu TSC values.
90+% likely you're not solving your problem correctly this way.
Yes, it was done as a last resort.
We need
On Fri, Feb 16, 2007 at 01:06:19PM -0800, Daniel Walker wrote:
On Fri, 2007-02-16 at 14:34 -0500, Jeff Muizelaar wrote:
It think it would be better if you had sometime like
'clocksource_get_clock_with_features()' that took flags describing the
needed characteristics instead of the unwanted
On Fri, 2007-02-16 at 17:10 -0500, Jeff Muizelaar wrote:
I still meant for _with_features to have same semantics so calling:
clocksource_get_clock_with_features(CLOCKSOURCE_PM_UNAFFECTED|CLOCKSOURCE_STABLE
|CLOCKSOURC_ATOMIC|CLOCKSOURCE_64BITS|CLOCKSOURCE_CONTINUOUS);
would be
On Fri, Feb 16, 2007 at 02:47:45PM -0800, Daniel Walker wrote:
Gets pretty ugly .. The clocksource interface already has a positive
rating to describe the best clocks in the system, which is used to
return the best clock .. Where the maintainers of the system give each
clock a rating.
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
I'd like to add support for recording a time stamp on each read and
write. Unfortunately, I am not sure which clock api I should use.
I had a look at blktrace
I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
I'd like to add support for recording a time stamp on each read and
write. Unfortunately, I am not sure which clock api I should use.
I had a look at blktrace
40 matches
Mail list logo
