[ltt-dev] [PATCH 2/3] ltt: rework trace clock code for SH

[Mathieu Desnoyers]

* Giuseppe CAVALLARO (peppe.cavallaro at st.com) wrote:
> Hi Mathieu,
> Mathieu Desnoyers wrote:
> >>  static inline u32 trace_clock_read32(void)
> >>  {
> >> -	return get_cycles();
> >> +	if (likely(clock))
> >> +		return (u32) clock->read(clock);
> > 
> > Can you walk us through the code that is executed when clock->read() is
> > called ?  Is it possible that the clock source read() takes a xtime seq
> > read lock in some SH configurations ?
> 
> On SH, the trace_clock_read_synthetic_tsc invokes the
> sh_tmu_clocksource_read (clock->read), in drivers/clocksource/sh_tmu.c.
> This reads the timer counter register (TCNT).
> 
> What do you think?

This particular implementation seems ok, but I'd like stronger
guarantees than that:

- That the clocksource selection will still work on future kernel
  releases and other SH boards.
- That sh_tmu_clocksource_read will never *ever* take any lock in any
  future kernel version. Is that guaranteed by the clocksource API ?

Thanks,

Mathieu


> 
> Regards
> Giuseppe
> 
> > If it is the case, then we will run into deadlocks with tracing code
> > called from within the xtime seq write lock. Therefore, fixing this
> > without calling the clocksource read() would be adequate.
> > 
> > Thanks,
> > 
> > Mathieu
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com