linux-kernel - Re: [ltt-dev] keypad/touchscreen driver events latencies using LTTng on ARM?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Dec 2008 05:57:37 -0500
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
Cc:	ltt-dev@...ts.casi.polymtl.ca, linux-kernel@...r.kernel.org
Subject: Re: [ltt-dev] keypad/touchscreen driver events latencies using
	LTTng on ARM?

* Russell King (rmk+lkml@....linux.org.uk) wrote:
> On Mon, Dec 01, 2008 at 05:35:02AM -0500, Mathieu Desnoyers wrote:
> > However, I wonder if some of the newer ARM boards would happen to have a
> > cycle counter (timestamp counter), so we could implement a get_cycles()
> > and trace clock for them ?
> 
> There continues to be nothing architected for that - it would be very
> SoC specific and the precision and resolution is very variable if it's
> provided at all.  About the best implementation is a 32-bit counter
> being clocked at various rates depending on the implementation.
> 
> Our best implementation is used for sched_clock() with all the
> cnt32_to_63() stuff to extend the size of the counter which as we've
> seen from other threads, may cause problems if used for other purposes.
> 
> The next best implementation is probably the hrtimer stuff.
> 

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.

That should be pretty much straightforward to do. Basically starting
from the MIPS trace clock I already have should make it trivial.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/