[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140816141159.GA8709@redhat.com>
Date: Sat, 16 Aug 2014 16:11:59 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: riel@...hat.com
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org,
umgwanakikbuti@...il.com, fweisbec@...il.com,
akpm@...ux-foundation.org, srao@...hat.com, lwoodman@...hat.com,
atheurer@...hat.com
Subject: Re: [PATCH 2/3] time,signal: protect resource use statistics with
seqlock
On 08/15, riel@...hat.com wrote:
>
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -288,18 +288,31 @@ void thread_group_cputime(struct task_struct *tsk, struct task_cputime *times)
> struct signal_struct *sig = tsk->signal;
> cputime_t utime, stime;
> struct task_struct *t;
> -
> - times->utime = sig->utime;
> - times->stime = sig->stime;
> - times->sum_exec_runtime = sig->sum_sched_runtime;
> + unsigned int seq, nextseq;
>
> rcu_read_lock();
> - for_each_thread(tsk, t) {
> - task_cputime(t, &utime, &stime);
> - times->utime += utime;
> - times->stime += stime;
> - times->sum_exec_runtime += task_sched_runtime(t);
> - }
> + /* Attempt a lockless read on the first round. */
> + nextseq = 0;
> + do {
> + seq = nextseq;
> + read_seqbegin_or_lock(&sig->stats_lock, &seq);
> + times->utime = sig->utime;
> + times->stime = sig->stime;
> + times->sum_exec_runtime = sig->sum_sched_runtime;
> +
> + for_each_thread(tsk, t) {
> + task_cputime(t, &utime, &stime);
> + times->utime += utime;
> + times->stime += stime;
> + times->sum_exec_runtime += task_sched_runtime(t);
> + }
> + /*
> + * If a writer is currently active, seq will be odd, and
> + * read_seqbegin_or_lock will take the lock.
> + */
> + nextseq = raw_read_seqcount(&sig->stats_lock.seqcount);
> + } while (need_seqretry(&sig->stats_lock, seq));
> + done_seqretry(&sig->stats_lock, seq);
> rcu_read_unlock();
> }
Rik, I do not understand why did you silently ignore my comments about
this change twice ;)
Please see
http://marc.info/?l=linux-kernel&m=140802271907396
http://marc.info/?l=linux-kernel&m=140811486607850
I still do not think that the read_seqbegin_or_lock logic is correct,
in a sense that unless I missed something it does not guarantee the
forward progress.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists