On Tue, Oct 20, 2015 at 1:36 PM, Chris Metcalf <cmetc...@ezchip.com> 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
--
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
