Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1290865
| From | Yuyang Du <yuyang.du@intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems |
| Date | 2015-12-14 07:30 +0100 |
| Message-ID | <qFuNX-2nd-3@gated-at.bofh.it> (permalink) |
| References | <qEvsL-4sJ-27@gated-at.bofh.it> <qEvVM-4Wy-15@gated-at.bofh.it> <qEw5t-52w-39@gated-at.bofh.it> <qEwoO-5c5-9@gated-at.bofh.it> <qEA94-7FL-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Fri, Dec 11, 2015 at 05:57:51PM +0000, Morten Rasmussen wrote:
> > >>> if (atomic_long_read(&cfs_rq->removed_load_avg)) {
> > >>> - long r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> > >>> + s64 r = atomic_long_xchg(&cfs_rq->removed_load_avg, 0);
> > >>> sa->load_avg = max_t(long, sa->load_avg - r, 0);
> > >>> sa->load_sum = max_t(s64, sa->load_sum - r * LOAD_AVG_MAX, 0);
> > >>
> > >> This makes sense, because sched_avg::load_sum is u64.
>
> A single removed nice=-20 task should be sufficient to cause the
> overflow.
Oh yes, it was a wreck, sorry.
> > >>> if (atomic_long_read(&cfs_rq->removed_util_avg)) {
> > >>> - long r = atomic_long_xchg(&cfs_rq->removed_util_avg, 0);
> > >>> + s64 r = atomic_long_xchg(&cfs_rq->removed_util_avg, 0);
> > >>> sa->util_avg = max_t(long, sa->util_avg - r, 0);
> > >>> sa->util_sum = max_t(s32, sa->util_sum - r * LOAD_AVG_MAX, 0);
> > >>> }
> > >>
> > >> However sched_avg::util_sum is u32, so this is still wrecked.
> > >
> > > I seems to have wrecked that in:
> > >
> > > 006cdf025a33 ("sched/fair: Optimize per entity utilization tracking")
> > >
> > > maybe just make util_load u64 too?
>
> It isn't as bad, but the optimization does increase the normal range
> (not guaranteed) for util_sum from 47742 to
> scale_down(SCHED_LOAD_SCALE)*47742 (= 1024*47742, unless you mess with
> the scaling).
>
> > Is there any guarantee that the final result of expression 'util_sum - r * LOAD_AVG_MAX' always can be represented by s32?
> >
> > If yes, than we could just do this:
> > max_t(s32, (u64)sa->util_sum - r * LOAD_AVG_MAX, 0)
>
> In most cases 'r' shouldn't exceed 1024 and util_sum not significantly
> exceed 1024*47742, but in extreme cases like spawning lots of new tasks
> it may potentially overflow 32 bit. Newly created tasks contribute
> 1024*47742 each to the rq util_sum, which means that more than ~87 new
> tasks on a single rq will get us in trouble I think.
>
> Without Peter's optimization referenced above, that number should
> increase to ~87k tasks as each task only contributed 47742 before, but
> 'r' could still cause 32-bit overflow if we remove more than ~87 newly
> created tasks in one go. But I'm not sure if that is a situation we
> should worry about?
>
> I think we have to either make util_sum u64 too or look at the
> optimizations again.
Both can workaround the issue with additional overhead. But I suspectthey
will end up going in the wrong direction for util_avg. The question is a
big util_sum (much bigger than 1024) may not be in a right range for it
to be used in load balancing.
The problem is that it is not so good to initiate a new task's util_avg
to 1024. At least, it makes much less sense than a new task's load_avg
being initiated to its full weight. Because the top util_avg should be
well bounded by 1024 - the CPU's full utilization.
So, maybe give the initial util_sum to an average of its cfs_rq, like:
cfs_rq->avg.util_sum / cfs_rq->load.weight * task->load.weight
And make sure that initial value's is bounded on various conditions.
Thanks,
Yuyang
--
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/
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Yuyang Du <yuyang.du@intel.com> - 2015-12-14 07:30 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Peter Zijlstra <peterz@infradead.org> - 2015-12-14 13:00 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Morten Rasmussen <morten.rasmussen@arm.com> - 2015-12-14 14:10 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Peter Zijlstra <peterz@infradead.org> - 2015-12-14 15:30 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Morten Rasmussen <morten.rasmussen@arm.com> - 2015-12-14 15:50 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Yuyang Du <yuyang.du@intel.com> - 2015-12-15 11:10 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Steve Muckle <steve.muckle@linaro.org> - 2015-12-15 23:00 +0100
Re: [PATCH] sched/fair: fix mul overflow on 32-bit systems Yuyang Du <yuyang.du@intel.com> - 2015-12-18 11:20 +0100
csiph-web