Messages in this thread | | | Date | Mon, 26 Aug 2013 16:42:58 +0800 | Subject | Re: [PATCH 03/10] sched: Clean-up struct sd_lb_stat | From | Lei Wen <> |
| |
On Mon, Aug 26, 2013 at 12:36 PM, Paul Turner <pjt@google.com> wrote: > On Sun, Aug 25, 2013 at 7:56 PM, Lei Wen <adrian.wenl@gmail.com> wrote: >> On Tue, Aug 20, 2013 at 12:01 AM, Peter Zijlstra <peterz@infradead.org> wrote: >>> From: Joonsoo Kim <iamjoonsoo.kim@lge.com> >>> >>> There is no reason to maintain separate variables for this_group >>> and busiest_group in sd_lb_stat, except saving some space. >>> But this structure is always allocated in stack, so this saving >>> isn't really benificial [peterz: reducing stack space is good; in this >>> case readability increases enough that I think its still beneficial] >>> >>> This patch unify these variables, so IMO, readability may be improved. >>> >>> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> >>> [peterz: lots of style edits, a few fixes and a rename] >>> Signed-off-by: Peter Zijlstra <peterz@infradead.org> >>> Link: http://lkml.kernel.org/r/1375778203-31343-4-git-send-email-iamjoonsoo.kim@lge.com >>> --- >>> kernel/sched/fair.c | 225 +++++++++++++++++++++++++--------------------------- >>> 1 file changed, 112 insertions(+), 113 deletions(-) >>> >>> --- a/kernel/sched/fair.c >>> +++ b/kernel/sched/fair.c >>> @@ -4277,36 +4277,6 @@ static unsigned long task_h_load(struct >>> >> [snip]... >>> - env->imbalance = DIV_ROUND_CLOSEST( >>> - sds->max_load * sds->busiest->sgp->power, SCHED_POWER_SCALE); >>> + env->imbalance = DIV_ROUND_CLOSEST(sds->busiest_stat.avg_load * >>> + sds->busiest->sgp->power, SCHED_POWER_SCALE); >>> >> >> I am wondering whether we could change this line as below is more appropriate, >> since it would avoid the division here: >> env->imbalance = (sds->busiest_stat.avg_load * sds->busiest->sgp->power) >> >> SCHED_POWER_SHIFT; >> >> I am not sure whether compiler would be smarter enough to covert into >>>> operation, >> if it see SCHED_POWER_SCALE is 1024 here. > > This would change the rounding. Fortunately, gcc is smart enough to > handle this.
Indeed, I check the assembly code, and it is really smart to do the changes.
Thanks, Lei
| |