* Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > 2013/4/10 Ingo Molnar <mingo@xxxxxxxxxx>: > > > > * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > > > >> Of course 128 bits ops are very expensive, so to help you evaluating the > >> situation, this is going to happen on every call to task_cputime_adjusted() and > >> thread_group_adjusted(), namely: > > > > It's really only expensive for divisions. Addition and multiplication should be > > straightforward and relatively low overhead, especially on 64-bit platforms. > > Ok, well we still have one division in the scaling path. I'm mostly > worried about the thread group exit that makes use of it through > threadgroup_cputime_adjusted(). Not sure if we can avoid that. I see, scale_stime()'s use of div64_u64_rem(), right? I swapped out the details already, is there a link or commit ID that explains where we hit 64-bit multiplication overflow? It's due to accounting in nanosecs, spread out across thousands of tasks potentially, right? But even with nsecs, a 64-bit variable ought to be able to hold hundreds of years worth of runtime. How do we overflow? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html