On 11/08/2020 02:41, benbjiang(蒋彪) wrote: > Hi, > >> On Aug 10, 2020, at 9:24 PM, Dietmar Eggemann <dietmar.eggem...@arm.com> >> wrote: >> >> On 06/08/2020 17:52, benbjiang(蒋彪) wrote: >>> Hi, >>> >>>> On Aug 6, 2020, at 9:29 PM, Dietmar Eggemann <dietmar.eggem...@arm.com> >>>> wrote: >>>> >>>> On 03/08/2020 13:26, benbjiang(蒋彪) wrote: >>>>> >>>>> >>>>>> On Aug 3, 2020, at 4:16 PM, Dietmar Eggemann <dietmar.eggem...@arm.com> >>>>>> wrote: >>>>>> >>>>>> On 01/08/2020 04:32, Jiang Biao wrote: >>>>>>> From: Jiang Biao <benbji...@tencent.com>
[...] >> Because of this very small weight (weight=3), compared to a SCHED_NORMAL >> nice 0 task (weight=1024), a SCHED_IDLE task is penalized by a huge >> se->vruntime value (1024/3 higher than for a SCHED_NORMAL nice 0 task). >> This should make sure it doesn't tick preempt a SCHED_NORMAL nice 0 task. > Could you please explain how the huge penalization of vruntime(1024/3) could > make sure SCHED_IDLE not tick preempting SCHED_NORMAL nice 0 task? > > Thanks a lot. Trace a run of 2 SCHED_OTHER (nice 0) tasks and 1 SCHED_IDLE task on a single CPU and trace_printk the conditions 'if (delta < 0)' and ' if (delta > ideal_runtime)' in check_preempt_tick(). Then do the same with 3 SCHED_OTHER (nice 0) tasks. You can also change the niceness of the 2 SCHED_OTHER task to 19 to see some differences in the kernelshark's task layout. rt-app (https://github.com/scheduler-tools/rt-app) is a nice tool to craft those artificial use cases. [...]
