Re: [PATCH] fix granularity of task_u/stime(), v2

[Stanislaw Gruszka <sgruszka@redhat.com>]

On Thu, Nov 12, 2009 at 03:49:19PM +0100, Stanislaw Gruszka wrote:
> On Thu, Nov 12, 2009 at 01:33:45PM +0900, Hidetoshi Seto wrote:
> > Originally task_s/utime() were designed to return clock_t but later
> > changed to return cputime_t by following commit:
> > 
> >   commit efe567fc8281661524ffa75477a7c4ca9b466c63
> >   Author: Christian Borntraeger <borntraeger@de.ibm.com>
> >   Date:   Thu Aug 23 15:18:02 2007 +0200
> > 
> > It only changed the type of return value, but not the implementation.
> > As the result the granularity of task_s/utime() is still that of
> > clock_t, not that of cputime_t.
> > 
> > So using task_s/utime() in __exit_signal() makes values accumulated
> > to the signal struct to be rounded and coarse grained.
> > 
> > This patch removes casts to clock_t in task_u/stime(), to keep
> > granularity of cputime_t over the calculation.
> > 
> > v2:
> >   Use div_u64() to avoid error "undefined reference to `__udivdi3`"
> >   on some 32bit systems.
> > 
> > Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
> > ---
> >  kernel/sched.c |   22 +++++++++++++---------
> >  1 files changed, 13 insertions(+), 9 deletions(-)
> 
> Patch not fix the issue on my system. I test it alone, together with 
> 
> posix-cpu-timers: avoid do_sys_times() races with __exit_signal(
> 
> and (further) together with
>  
> --- a/kernel/posix-cpu-timers.c
> +++ b/kernel/posix-cpu-timers.c
> @@ -248,8 +248,8 @@ void thread_group_cputime(struct task_struct *tsk,
> struct task_cputime *times)
> 
>         t = tsk;
>         do {
> -               times->utime = cputime_add(times->utime, t->utime);
> -               times->stime = cputime_add(times->stime, t->stime);
> +               times->utime = cputime_add(times->utime, task_utime(t));
> +               times->stime = cputime_add(times->stime, task_stime(t));
>                 times->sum_exec_runtime += t->se.sum_exec_runtime;
> 
>                 t = next_thread(t);
> 
> What only changed was probability to enter the issue.

I was wrong here, that combination fix the problem on my system. I don't
know how I was testing it before, perhaps I booted wrong kernel.

Stanislaw