On Fri, Oct 01, 2021 at 04:35:58PM +1300, Barry Song wrote: > On Fri, Sep 17, 2021 at 4:36 AM Roman Gushchin <guro@xxxxxx> wrote: > > > > This patch adds 3 hooks to control wakeup and tick preemption: > > cfs_check_preempt_tick > > cfs_check_preempt_wakeup > > cfs_wakeup_preempt_entity > > > > The first one allows to force or suppress a preemption from a tick > > context. An obvious usage example is to minimize the number of > > non-voluntary context switches and decrease an associated latency > > penalty by (conditionally) providing tasks or task groups an extended > > execution slice. It can be used instead of tweaking > > sysctl_sched_min_granularity. > > > > The second one is called from the wakeup preemption code and allows > > to redefine whether a newly woken task should preempt the execution > > of the current task. This is useful to minimize a number of > > preemptions of latency sensitive tasks. To some extent it's a more > > flexible analog of a sysctl_sched_wakeup_granularity. > > This reminds me of Mel's recent work which might be relevant: > sched/fair: Scale wakeup granularity relative to nr_running > https://lore.kernel.org/lkml/20210920142614.4891-3-mgorman@xxxxxxxxxxxxxxxxxxx/ Oh, this is interesting, thank you for the link! This is a perfect example of a case when bpf can be useful if the change will be considered to be too special to be accepted in the mainline code. > > > > > The third one is similar, but it tweaks the wakeup_preempt_entity() > > function, which is called not only from a wakeup context, but also > > from pick_next_task(), which allows to influence the decision on which > > task will be running next. > > > > It's a place for a discussion whether we need both these hooks or only > > one of them: the second is more powerful, but depends more on the > > current implementation. In any case, bpf hooks are not an ABI, so it's > > not a deal breaker. > > I am also curious if similar hook can benefit > newidle_balance/sched_migration_cost > tuning things in this thread: > https://lore.kernel.org/lkml/ef3b3e55-8be9-595f-6d54-886d13a7e2fd@xxxxxxxxxxxxx/ > > It seems those static values are not universal. different topology might need > different settings. but dynamically tuning them in the kernel seems to be > extremely difficult. Absolutely! I'm already playing with newidle_balance (no specific results yet). And sched_migration_cost is likely a good target too! Thanks!
