On 07/24/2015 09:27 AM, Frederic Weisbecker wrote:
On Mon, Jul 13, 2015 at 03:57:57PM -0400, Chris Metcalf wrote:
+{
+ struct clock_event_device *dev =
+ __this_cpu_read(tick_cpu_device.evtdev);
+ struct task_struct *task = current;
+ unsigned long start = jiffies;
+ bool warned = false;
+
+ /* Drain the pagevecs to avoid unnecessary IPI flushes later. */
+ lru_add_drain();
+
+ while (READ_ONCE(dev->next_event.tv64) != KTIME_MAX) {
+ if (!warned && (jiffies - start) >= (5 * HZ)) {
+ pr_warn("%s/%d: cpu %d: cpu_isolated task blocked for %ld
seconds\n",
+ task->comm, task->pid, smp_processor_id(),
+ (jiffies - start) / HZ);
+ warned = true;
+ }
+ if (should_resched())
+ schedule();
+ if (test_thread_flag(TIF_SIGPENDING))
+ break;
+ tick_nohz_cpu_isolated_wait();
If we call cpu_idle(), what is going to wake the CPU up if no further interrupt
happen?
We could either implement some sort of tick waiters with proper wake up once
the CPU sees
no tick to schedule. Arguably this is all risky because this involve a
scheduler wake up
and thus the risk for new noise. But it might work.
Another possibility is an msleep() based wait. But that's about the same, maybe
even worse
due to repetitive wake ups.
The presumption here is that it is not possible to have
tick_cpu_device have a pending next_event without also
having a timer interrupt pending to go off. That certainly
seems to be true on the architectures I have looked at.
Do we think that might ever not be the case?
We are running here with interrupts disabled, so this core won't
transition from "timer interrupt scheduled" to "no timer interrupt
scheduled" before we spin or idle, and presumably no other core
can reach across and turn off our timer interrupt either.
--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
