Re: [PATCH v8 04/14] task_isolation: add initial support

On Tue, Oct 20, 2015 at 1:36 PM, Chris Metcalf [off-list ref] wrote:

+/*
+ * In task isolation mode we try to return to userspace only after
+ * attempting to make sure we won't be interrupted again.  To handle
+ * the periodic scheduler tick, we test to make sure that the tick is
+ * stopped, and if it isn't yet, we request a reschedule so that if
+ * another task needs to run to completion first, it can do so.
+ * Similarly, if any other subsystems require quiescing, we will need
+ * to do that before we return to userspace.
+ */
+bool _task_isolation_ready(void)
+{
+       WARN_ON_ONCE(!irqs_disabled());
+
+       /* If we need to drain the LRU cache, we're not ready. */
+       if (lru_add_drain_needed(smp_processor_id()))
+               return false;
+
+       /* If vmstats need updating, we're not ready. */
+       if (!vmstat_idle())
+               return false;
+
+       /* If the tick is running, request rescheduling; we're not ready. */
+       if (!tick_nohz_tick_stopped()) {
+               set_tsk_need_resched(current);
+               return false;
+       }
+
+       return true;
+}

I still don't get why this is a loop.

I would argue that this should simply drain the LRU, quiet vmstat, and
return.  If the tick isn't stopped, then there's a reason why it's not
stopped (which may involve having SCHED_OTHER tasks around, in which
case user code shouldn't do that or there should simply be a
requirement that isolation requires a real-time scheduler class).

BTW, should isolation just be a scheduler class (SCHED_ISOLATED)?

--Andy