On 08/14, Oleg Nesterov wrote:
>
> OK, lets forget about alternative approach for now. We can reconsider
> it later. At least I have to admit that seqlock is more straighforward.

Yes.

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.

And of course, stats_lock is more generic.

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