Hi Peter. Thanks for looking into the patches.
On 9/25/26 1:13 PM, Peter Zijlstra wrote:
On Wed, Sep 09, 2026 at 07:26:10PM +0530, Shrikanth Hegde wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a689a0cea4eb..b4ef2e92d786 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2504,6 +2504,23 @@ static inline bool rq_has_pinned_tasks(struct rq *rq)
return rq->nr_pinned;
}
+static inline bool task_can_sched_on_preferred(int cpu, struct task_struct *p)
(somehow those arguments feel backwards)
+{
+ if (cpu_preferred(cpu))
+ return false;
FWIW, this reads very weird. task_can_sched_on_preferred() returning
false when task is on a preferred cpu.
How about below signature?
static inline bool task_can_migrate_to_preferred(struct task_struct *p, int cpu)
The question really is more like: can we migrate to a preferred CPU, and
in that context it makes more sense. No point in migrating if we are
already on one.
Perhaps a comment on top of the function can clarify?
Above new function name is self explanatory IMHO.
+ /* Only FAIR tasks honor preferred CPU state */
+ if (unlikely(p->sched_class != &fair_sched_class))
+ return false;
+
+ /* Ignore preferred state if task affinity is changing */
+ if (unlikely(!cpumask_test_cpu(task_cpu(p), p->cpus_ptr)))
+ return false;
+
+ return cpumask_intersects_and(p->cpus_ptr, cpu_preferred_mask,
+ task_cpu_possible_mask(p));
+}
