Re: [PATCH] sched/rt: don't try to balance rt_runtime when it is futile

[Mike Galbraith <umgwanakikbuti@gmail.com>]

On Wed, 2014-05-14 at 15:11 -0400, Paul Gortmaker wrote:

> Given that, perhaps a separate change to sched_rt_runtime_exceeded()
> that works out the CPU from the rt_rq, and returns zero if it is a
> nohz_full cpu?  Does that make sense?  Then the nohz_full people won't
> get the throttling message even if they go 100%.

I don't get it.  What reason would there be to run a hog on a dedicated
core as realtime policy/priority?  Given no competition, there's nothing
to prioritize, you could just as well run a critical task as SCHED_IDLE.

I would also expect that anyone wanting bare metal will have all of
their critical cores isolated from the scheduler, watchdogs turned off
as well as that noisy throttle, the whole point being to make as much
silent as possible.  Seems to me tick_nohz_full_cpu(cpu) should be
predicated by that cpu being isolated from the #1 noise source, the
scheduler and its load balancing.  There's just no point to nohz_full
without that, or if there is, I sure don't see it.

When I see people trying to run a hog as a realtime task, it's because
they are trying in vain to keep competition away from precious cores..
and one mlockall with a realtime hog blocking flush_work() gives them a
wakeup call.

-Mike