Wakeup latency measured with SCHED_TRACER depends on HZ

[Stanislav Meduna <stano@meduna.org>]

Hi,

on an embedded platform using a Freescale i.MX28 ARM processor
I am experiencing a strange phenomenon - the latencies reported
are dependent of HZ in the way such as:

# cat timerandwakeup/max_latency-CPU0

HZ 500:
459 15 2499 (499) myApp <- 284 -6 mmcqd/1 273.436000

HZ 100:
459 15 10453 (453) myApp <- 284 -6 mmcqd/1 273.436000


The wakeup/max_latency is always exactly one HZ tick

# cat wakeup/max_latency-CPU0
233 50 2000 (0) irq/101-imx28-f <- 0 -21 swapper 121.764000


All the timestamps in e.g. dmesg output also exhibit the HZ
granularity (this is definitely not the case on an x86),
so I'd say the interpolation somehow does not work.
The hardware counter itself increments at 32 kHz (at least
clocksource_mmio_init is called with 32000 in hz parameter).

Date +%N (show nanosecond part of current time) does not
exhibit the same rounding.


Anyone has an idea where to start the search? I understand
that as I am probably the first one experimenting with RT
on this platform I am basically on my own here, I'd just
appreciate pointers to relevant information on the timing
infrastructure.

I am using 3.4.15-rt24 with some patches ported from an older
non-RT kernel provided by the platform vendor. However, none
of those patches touches clock/time handling, so these are from
mainline (arch/arm/mach-mxs/timer.c etc).

Thanks
-- 
                                    Stano