Messages in this thread Patch in this message | | | Subject | Re: [PATCH] sched: prevent compiler from optimising sched_avg_update loop | From | Eric Dumazet <> | Date | Tue, 23 Mar 2010 18:53:24 +0100 |
| |
Le mardi 23 mars 2010 à 17:36 +0000, Will Deacon a écrit : > GCC 4.4.1 on ARM has been observed to replace the while loop > in sched_avg_update with a call to uldivmod, resulting in the > following build failure at link-time: > > kernel/built-in.o: In function `sched_avg_update': > /linux-2.6/kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' > /linux-2.6/kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod' > make: *** [.tmp_vmlinux1] Error 1 > > This patch [taken against 2.6.34-rc2] replaces the loop with a call to > div_s64 which allows the Kernel to link. > > Cc: Catalin Marinas <catalin.marinas@arm.com> > Cc: Ingo Molnar <mingo@elte.hu> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Peter Zijlstra <peterz@infradead.org> > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- > kernel/sched.c | 7 +++---- > 1 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/kernel/sched.c b/kernel/sched.c > index 9ab3cd7..6b74f21 100644 > --- a/kernel/sched.c > +++ b/kernel/sched.c > @@ -1238,11 +1238,10 @@ static u64 sched_avg_period(void) > static void sched_avg_update(struct rq *rq) > { > s64 period = sched_avg_period(); > + s64 elapsed_periods = div_s64(rq->clock - rq->age_stamp - 1, period); > > - while ((s64)(rq->clock - rq->age_stamp) > period) { > - rq->age_stamp += period; > - rq->rt_avg /= 2; > - } > + rq->age_stamp += (u64)(elapsed_periods * period); > + rq->rt_avg >>= elapsed_periods; > } > > static void sched_rt_avg_update(struct rq *rq, u64 rt_delta)
Please take a look at __iter_div_u64_rem() , because we had a similar problem in the past. We want to avoid this div_s64() call.
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |