On Tue, Mar 26, 2013 at 03:19:25PM +0100, Frederic Weisbecker wrote: > I starred at that code for quite some time already and I can't come up > with a better solution. > > 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: > > * Some proc files read > * sys_times() > * thread group exit I need to think if we can get rid of thread_group_cputime_adjusted() at exit(), perhaps this is possible without causing problems. Div128 is optimized if higher 64-bits are zeros. 128 bit multiplication can be avoided if we are sure that 64bit mul will not overflow, for example: if (ffs(stime) + ffs(rtime) < 64) scale_64() else scale_128() Basically 99.9% of processes will go scale_64() path. Fix is only needed for processes that utilize lot of CPU time for long period, hence have big stime and rtime values, what is not common. I'm thinking also about remove cputime scaling. Obviously this would be the best regarding performance. I think we could avoid multiplication in kernel, this can be done in user-space if we export rtime to it. So top could be modified to do cputime scaling by itself. In that way we will avoid this top hiding "exploit", but also precision of times(2) syscall values will get worse (I think there are lot of programs that use this call and they might expect stime/utime are precise). Stanislaw -- 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