On 10/08/20 07:14, Srikar Dronamraju wrote: > * Josh Don <[email protected]> [2020-08-04 12:34:13]: > >> SMT siblings share caches, so cache hotness should be irrelevant for >> cross-sibling migration. >> >> Proposed-by: Venkatesh Pallipadi <[email protected]> >> Signed-off-by: Josh Don <[email protected]> >> --- >> kernel/sched/fair.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 1a68a0536add..abdb54e2339f 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -7402,6 +7402,10 @@ static int task_hot(struct task_struct *p, struct >> lb_env *env) >> if (unlikely(task_has_idle_policy(p))) >> return 0; >> >> + /* SMT siblings share cache */ >> + if (env->sd->flags & SD_SHARE_CPUCAPACITY) >> + return 0; >> + > > If this for retaining cache hotness, should we look at > SD_SHARE_PKG_RESOURCES instead of SD_SHARE_CPUCAPACITY? >
Josh's patch only targets migrating tasks between threads of the same core - as he points out, cache hotness shouldn't matter here. Using SD_SHARE_PKG_RESOURCES here would mean freely migrating tasks between any CPU of an LLC domain, which is quite likely something you do *not* want to do. >> /* >> * Buddy candidates are cache hot: >> */ >> -- >> 2.28.0.163.g6104cc2f0b6-goog >>
