Messages in this thread | | | Date | Thu, 18 Dec 2014 10:10:51 +0800 | From | Yuyang Du <> | Subject | Re: sched: odd values for effective load calculations |
| |
On Tue, Dec 16, 2014 at 12:29:28AM -0500, Sasha Levin wrote: > On 12/15/2014 08:14 AM, Peter Zijlstra wrote: > >>>> [ 787.894288] ================================================================================ > >>>> > > > [ 787.897074] UBSan: Undefined behaviour in kernel/sched/fair.c:4541:17 > >>>> > > > [ 787.898981] signed integer overflow: > >>>> > > > [ 787.900066] 361516561629678 * 101500 cannot be represented in type 'long long int' > >> > > >> > So that's: > >> > > >> > this_eff_load *= this_load + > >> > effective_load(tg, this_cpu, weight, weight); > >> > > >> > Going by the numbers the 101500 must be 'this_eff_load', 100 * ~1024 > >> > makes that. Which makes the rhs 'large'. Do you have > >> > CONFIG_FAIR_GROUP_SCHED enabled? If so, what kind of cgroup hierarchy > >> > are you using? > >> > > >> > In any case, bit sad this doesn't have a register dump included :/ > > Hmm, I was hoping to be able to see if it was this_load or the > > effective_load() result being silly large, but going by the ASM output > > of my compiler this isn't going to be available in registers, its all > > stack spills. > > > > Pinning my hopes on that reproducability thing :/ > > Okay, yeah, it's very reproducible. I've added: >
Hi Sasha,
I tried to reproduce this overflow, but got not luck (the trinity has been running in a KVM VM for an hour)...
The trinity used is v1.4, and simply launched as ./trinity.
Could you detail your setup and procedure?
Thanks, Yuyang
| |