Ingo Molnar wrote:
> * K.R. Foley <kr@cybsft.com> wrote:
> 
> 
>>>here's the code:
>>>
>>>+static inline void trace_start_sched_wakeup(task_t *p, runqueue_t *rq)
>>>+{
>>>+       if (TASK_PREEMPTS_CURR(p, rq) && (p != rq->curr) && 
>>>_need_resched())
>>>+               __trace_start_sched_wakeup(p);
>>>+}
>>>
>>>indeed this only triggers if the woken up task has a higher priority
>>>than the waker... hm. Could you try to reverse the priorities of 
>>>realfeel and IRQ8, does that produce traces?
>>
>>I guess I really am slow. You laid it all out for me above and I still
>>didn't get it until I looked at again. I still haven't been able to
>>capture an actual trace from any of these programs, but thanks to your
>>addition of logging all of the max latencies in 32-14 I can see that
>>the traces were there until another trace pushes them out.
> 
> 
> wakeup tracing can only work reliably if it's a higher-prio task that is
> being woken up (to which the currently executing task is obliged to
> preempt). Otherwise the currently executing task (the one which wakes up
> the other task) could continue to execute indefinitely, making the
> wakeup latency trace much less useful. Hence the priority check and the
> need_resched() check: 'is the wakee higher-prio', and 'does the current
> task really have to preempt right now'.
> 
> (hm, i think the _need_resched() check is in fact buggy, especially on
> SMP systems: if there's a cross-CPU wakeup then _need_resched() wont be
> set for the current task! Is this perhaps what you wanted to point out? 
> I've uploaded the -32-17 kernel which has the _need_resched() check
> removed.)
> 
> unfortunately this issue seems to hit realfeel/rtc_wakeup too: there the
> common wakeup is done from the IRQ thread, which is higher-prio than
> realfeel/rtc_wakeup! So wakeup tracing/timing doesnt get activated at
> all for those types of wakeups.

Also worth noting, unless I have my head up my rear again. If the waker 
is higher prio than the wakee (IRQ 8 is higher than rtc_wakeup) the 
wakee doesn't preempt the waker during the wakeup. It gets put into the 
runqueue but doesn't run until schedule gets called later (assuming 
there isn't another higher prio task queued). Where if the wakee is 
higher prio than the waker, it looks like it will preempt it in most 
cases, which I think is probably why there is such a difference being 
reported in the rtc histogram when the two priorities are switched.
> 
> a solution/workaround to this would be to 'reverse' the priorities of
> the tasks: i.e. to make the IRQ thread prio 80, and to make realfeel
> prio 90, and to look at the results. In theory realfeel shouldnt be
> running when the next IRQ arrives, so this should produce meaningful
> traces.

This seems to work quite well for realfeel because it doesn't burn the 
CPU while it's waiting on data. If an app doesn't just sleep or block 
waiting on data though couldn't it end up interfering with the IRQ thread?
> 
> 	Ingo
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/