Gregory Haskins wrote: > Hi Rik, > > Rik van Riel wrote: >> Gregory Haskins wrote: >> >>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
