On 08/14, Oleg Nesterov wrote:
>
> But just for record, the "lockless" version doesn't look that bad to me,
>
>       void thread_group_cputime(struct task_struct *tsk, struct task_cputime 
> *times)
>       {
>               struct signal_struct *sig = tsk->signal;
>               bool lockless, is_dead;
>               struct task_struct *t;
>               unsigned long flags;
>               u64 exec;
>
>               lockless = true;
>               is_dead = !lock_task_sighand(p, &flags);
>        retry:
>               times->utime = sig->utime;
>               times->stime = sig->stime;
>               times->sum_exec_runtime = exec = sig->sum_sched_runtime;
>               if (is_dead)
>                       return;
>
>               if (lockless)
>                       unlock_task_sighand(p, &flags);
>
>               rcu_read_lock();
>               for_each_thread(tsk, t) {
>                       cputime_t utime, stime;
>                       task_cputime(t, &utime, &stime);
>                       times->utime += utime;
>                       times->stime += stime;
>                       times->sum_exec_runtime += task_sched_runtime(t);
>               }
>               rcu_read_unlock();
>
>               if (lockless) {
>                       lockless = false;
>                       is_dead = !lock_task_sighand(p, &flags);
>                       if (is_dead || exec != sig->sum_sched_runtime)
>                               goto retry;
>               }
>               unlock_task_sighand(p, &flags);
>       }
>
> The obvious problem is that we should shift lock_task_sighand() from the
> callers to thread_group_cputime() first, or add 
> thread_group_cputime_lockless()
> and change the current users one by one.

OTOH, it is simple to convert do_sys_times() and posix_cpu_clock_get_task()
to use the lockless version, and avoid the new stats_lock and other changes
it needs.

> And of course, stats_lock is more generic.

Yes, this is true in any case.

So I simply do not know.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to