[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20251112142119.375184-1-wanix1988@gmail.com>
Date: Wed, 12 Nov 2025 22:21:19 +0800
From: Linwei Wang <wanix1988@...il.com>
To: Aaron Lu <ziqianlu@...edance.com>
Cc: Linwei Wang <wanix1988@...il.com>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>,
Mel Gorman <mgorman@...e.de>,
Valentin Schneider <vschneid@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/fair: remove redundant se initialization in unthrottle_cfs_rq
Hi Aaron,
Your commit 956dfda6a708 removes the duplicate assignment after the early
return, but still initializes 'se' at declaration:
struct sched_entity *se = cfs_rq->tg->se[cpu_of(rq)];
This initialization happens before the early return check at line 6036-6037,
so when runtime_remaining <= 0 causes an early return, the array access
is wasted.
My patch defers initialization until after the early return:
- struct sched_entity *se = cfs_rq->tg->se[cpu_of(rq)];
+ struct sched_entity *se;
...
+ se = cfs_rq->tg->se[cpu_of(rq)];
Your commit fixes the duplicate assignment; mine optimizes the early return
path. They're independent optimizations.
Should I rebase on top of 956dfda6a708?
Thanks.
Powered by blists - more mailing lists