public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: ltt-dev@lists.casi.polymtl.ca, linux-kernel@vger.kernel.org
Subject: Re: [ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?
Date: Mon, 1 Dec 2008 06:41:46 -0500	[thread overview]
Message-ID: <20081201114146.GG25340@Krystal> (raw)
In-Reply-To: <20081201105956.GC28971@flint.arm.linux.org.uk>

* Russell King (rmk+lkml@arm.linux.org.uk) wrote:
> On Mon, Dec 01, 2008 at 05:57:37AM -0500, Mathieu Desnoyers wrote:
> > Ok, so for LTTng on ARM it would make sense to use the same clock source
> > as sched_clock for :
> > mach-pxa, mach-realview, mach-sa1100, mach-versatile, plat-omap.
> > 
> > We basically have, for each of these build scenarios, to take the mmio
> > clock used by sched_clock and use it through
> > kernel/trace/trace-clock-32-to-64 to extend it to 64-bits. Therefore we
> > won't suffer from any of the constrains linked to cnt32_to_63 and we
> > would be sure that the trace clock is correct wrt SMP wrt memory
> > barriers and cache line bouncing because it uses per-cpu data to keep
> > the counters.
> 
> Just remember that MMIO clock sources are not available until after
> setup_arch() has finished - in other words, they don't work when the
> kernel initially boots.  Accessing them too early will cause a page
> fault and hang the kernel.
> 

This can be dealt with by refusing the get_trace_clock(), which should
probably be allowed to fail if the underlying infrastructure is not
ready when the trace buffers are created. The tracer would therefore not
accept to start any sort of tracing too soon for the architecture being
used.

Mathieu


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

      reply	other threads:[~2008-12-01 11:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-30 18:00 keypad/touchscreen driver events latencies using LTTng on ARM? Trilok Soni
2008-12-01 10:35 ` Mathieu Desnoyers
2008-12-01 10:45   ` Russell King
2008-12-01 10:57     ` [ltt-dev] " Mathieu Desnoyers
2008-12-01 10:59       ` Russell King
2008-12-01 11:41         ` Mathieu Desnoyers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081201114146.GG25340@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox