Gregory Haskins wrote:

Hi Rik,

Rik van Riel wrote:

quoted

Gregory Haskins wrote:

quoted

2) Modify FIFO so that it disables tick by default...update accounting
info at next reschedule event.

I like it.  The only thing to watch out for is that
events that wake up higher-priority FIFO tasks do
not get deferred :)

Yeah, agreed.  My (potentially half-baked) proposal should work at least
from a pure scheduling perspective since FIFO technically does not
reschedule based on a tick, and wakeups/migrations should still work
bidirectionally with existing scheduler policies.

However, and to what I believe is your point: its not entirely clear to
me what impact, if any, there would be w.r.t. any _other_ events that
may be driven off of the scheduler tick (i.e. events other than
scheduling policies, like timeslice expiration, etc).  Perhaps someone
else like Thomas, Ingo, or Peter have some input here.

I guess the specific question to ask is: Does the scheduler tick code
have any role other than timeslice policies and updating accounting
information?  Examples would include timer-expiry, for instance.  I
would think most of this logic is handled by finer grained components
like HRT, but I am admittedly ignorant of the actual timer voodoo ;)

Thinking about this idea some more:  I can't see why this isn't just a
trivial variation of the nohz idle code already in mainline.  In both
cases (idle and FIFO tasks) the cpu is "consumed" 100% by some arbitrary
job (spinning/HLT for idle, RT thread for FIFO) while we have the
scheduler tick disabled.  The only real difference is a matter of
power-management (HLT/mwait go to sleep-states, whereas spinning/rt-task
run full tilt).

Therefore the answer may be as simple as bracketing the FIFO task with
tick_nohz_stop_sched_tick() + tick_nohz_restart_sched_tick().  The nohz
code will probably need some minor adjustments so it is not assuming
things about the state being "idle" (e.g. "isidle") for places when it
matters (idle_calls++ stat is one example).

Potential problems:

a) disabling/renabling the tick on a per-RT task schedule() may prove to
be prohibitively expensive.

b) we will need to make sure the rt-bandwidth protection mechanism is
defeated so the task is allowed to consume 100% bandwidth.

Perhaps these states should be in the cpuset/root-domain, and configured
when you create the partition (e.g. "tick=off", "bandwidth=off" makes it
an "offline" set).

Kind Regards,
-Greg