Linux HZ and Schedule Schedule

Question

In sched_fair.c it has:

 unsigned int sysctl_sched_latency = 5000000ULL //5m unsigned int sysctl_sched_min_granularity = 1000000ULL //1ms 

I understand that the Linux personal timeline varies depending on nr_running and the relative weight of this fair task, but as I studied the code, I realized that the main idea is to keep the time interval from 1 to 5 ms. Please correct me if I understand that this is wrong. I should be wrong here, but I just can't figure out how to do this.

Furthermore, knowing that HZ, or the number of system ticks per second or the number of timer interrupts every second, is usually 200 or 100 for a handheld device (and most other non-desktop computers), which gives us 5 10 ms.

Timeslice is put into action by running rq-> hrtick_timer in set_next_entity() , every time an honest task is scheduled, and calling resched_task() in the timeout hrtick() callback function. This timer is just one of the timers that are processed by the irq timer handler on each tick, timer_tick() ... run_local_timer() . There seems to be no other hidden secret.

Then how can we get timelis shorter than 5 ms? Please help me figure this out. Thank you very much!

Answer 1

As stated in Robert Love Linux Kernel Development, the only ways to reduce time are to increase the number of running processes (or those that have lower priority than others).

An increase in the number of running processes creates a need to shorten the time interval in order to guarantee an appropriate target delay (but the timeline below is limited with minimal detail). But there is no guarantee that the process will be unloaded in a given period of time. This is because time tracking is done using timer interrupts.

Increasing the HZ value causes timer interruptions to occur more often, which makes time tracking more valuable, so re-scheduling can occur more often.

---

The vruntime variable stores the virtual runtime of the process, which is the actual runtime, normalized by the number of running processes. In an ideal multi-tasking system, the vruntime of the entire process will be identical - all tasks would receive an equal, fair share of the processor.

Typically, a time period is a target latency divided by the number of running processes. But when the number of running processes approaches infinity, the time limit approaches 0. Since this ultimately leads to unacceptable switching costs, CFS overlays the time-list assigned to each process. This floor is called minimal detail. Thus, the time value is sysctl_sched_latency and sysctl_sched_granularity . (See sched_timeslice() )

vruntime variable is controlled by update_curr() . update_curr() is called periodically by the system timer, and also whenever the process becomes executable or is blocked, it becomes impossible.

To ensure prevention between tasks, hrtick() calls task_tick_fair() on each timer interrupt, which in turn calls entity_tick() . entity_tick() calls update_curr() to update the vruntime process, and then calls check_preempt_tick() . check_preempt_tick() checks if the current runtime is longer than the ideal runtime (timelice), if so, calls resched_task() , which sets the TIF_NEED_RESCHED flag.

When TIF_NEED_RESCHED set, schedule() is called as soon as possible.

Thus, with an increase in the HZ value, timer interruptions occur more often, which leads to more expensive time tracking and allows the scheduler to reconfigure tasks more often.