lkml.org 
[lkml]   [2021]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH rfc 4/6] sched: cfs: add bpf hooks to control wakeup and tick preemption
    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@fb.com> 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@techsingularity.net/

    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@hisilicon.com/
    >
    > 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!

    \
     
     \ /
      Last update: 2021-10-02 02:14    [W:3.104 / U:0.320 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site