Messages in this thread | | | Date | Fri, 9 Sep 2022 18:09:13 +0800 | From | Chen Yu <> | Subject | Re: [PATCH v5 3/5] sched/fair: Skip core update if task pending |
| |
On 2022-09-09 at 13:53:02 +0800, Abel Wu wrote: > The function __update_idle_core() considers this cpu is idle so > only checks its siblings to decide whether the resident core is > idle or not and update has_idle_cores hint if necessary. But the > problem is that this cpu might not be idle at that moment any > more, resulting in the hint being misleading. > > It's not proper to make this check everywhere in the idle path, > but checking just before core updating can make the has_idle_core > hint more reliable with negligible cost. > > Signed-off-by: Abel Wu <wuyun.abel@bytedance.com> > --- > kernel/sched/fair.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 7abe188a1533..fad289530e07 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -6294,6 +6294,9 @@ void __update_idle_core(struct rq *rq) > int core = cpu_of(rq); > int cpu; > > + if (rq->ttwu_pending) > + return; > + Is it to deal with the race condition? I'm thinking of the following scenario: task p1 on rq1 is about to switch to idle. However when p1 reaches __update_idle_core(), someone on other CPU tries to wake up p2, and leverages rq1 to queue p2 thus set the ttwu_pending flag on rq1. It is likely that rq1 becomes idle but soon finds that TF_NEED_RESCHED is set, thus quits the idle loop. As a result rq will not be idle and we will get false positive here.
thanks, Chenyu > rcu_read_lock(); > if (test_idle_cores(core, true)) > goto unlock; > -- > 2.37.3 >
| |