Messages in this thread | | | Date | Sun, 04 Mar 2007 06:14:41 -0500 | From | Andres Salomon <> | Subject | Re: [PATCH] dynticks: don't unlock spinlock twice |
| |
Thomas Gleixner wrote: > On Fri, 2007-03-02 at 21:52 -0500, Andres Salomon wrote: [...] > > The BUG is somewhere else. the tick timer should never be seen in > hrtimer_run_queues. The tick timer is operated solely from the timer > interrupt. > > The question is, how the tick timer gets enqueued in the softirq queue. > Can you isolate the codepath, where this happens ? >
Only 4 functions call timer->function; hrtimer_enequeue_reprogram, hrtimer_interrupt, run_hrtimer_softirq, and run_hrtimer_queue.
- hrtimer_enqueue_reprogram will not call CB_IRQSAFE_NO_SOFTIRQ; this function is not the culprit. It does move CB_SOFTIRQs onto the cb_pending list.
- hrtimer_interrupt is called from a hardirq context, and only runs CB_IRQSAFE*. CB_SOFTIRQs are moved onto the cb_pending list. Since irqs are disabled, this function is not the culprit.
- run_hrtimer_softirq is called from the HRTIMER_SOFTIRQ, and only operates on softirqs (via the cb_pending list). CB_IRQSAFE_NO_SOFTIRQ callbacks are never added to the cb_pending list, so this function is not the culprit.
- run_hrtimer_queue is called from TIMER_SOFTIRQ, and runs on all timers. This function is what shows up in the backtrace, and should not be calling tick_sched_timer.
Now, the question is; what *should* it be doing? Since it is only ever run from a softirq context, should it be checking for !CB_IRQSAFE_NO_SOFTIRQ before running the timers? Should it only be processing timers that have been added to cb_pending (which are guaranteed to be softirq-friendly)? Is there even a reason why we have a run_hrtimer_softirq that processes cb_pending, as well as a run_timer_softirq that calls hrtimer_run_queues? Why should the timer softirq (which is raised by, amongst other things, update_process_times, which is called by our friend tick_sched_timer) care about the hrtimer queues?
- 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/
| |