From: Oleg Nesterov <oleg@redhat.com>
To: Jason Low <jason.low2@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Galbraith <umgwanakikbuti@gmail.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Rik van Riel <riel@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Scott Norton <scott.norton@hp.com>,
Aswin Chandramouleeswaran <aswin@hp.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] sched, timer: Use atomics for thread_group_cputimer to improve scalability
Date: Mon, 2 Mar 2015 20:40:33 +0100 [thread overview]
Message-ID: <20150302194033.GA27914@redhat.com> (raw)
In-Reply-To: <1425321731.5304.14.camel@j-VirtualBox>
Well, I forgot everything about this code, but let me ask anyway ;)
On 03/02, Jason Low wrote:
>
> -static void update_gt_cputime(struct task_cputime *a, struct task_cputime *b)
> +static inline void __update_gt_cputime(atomic64_t *cputime, u64 sum_cputime)
> {
> - if (b->utime > a->utime)
> - a->utime = b->utime;
> -
> - if (b->stime > a->stime)
> - a->stime = b->stime;
> + u64 curr_cputime;
> + /*
> + * Set cputime to sum_cputime if sum_cputime > cputime. Use cmpxchg
> + * to avoid race conditions with concurrent updates to cputime.
> + */
> +retry:
> + curr_cputime = atomic64_read(cputime);
> + if (sum_cputime > curr_cputime) {
> + if (atomic64_cmpxchg(cputime, curr_cputime, sum_cputime) != curr_cputime)
> + goto retry;
> + }
> +}
>
> - if (b->sum_exec_runtime > a->sum_exec_runtime)
> - a->sum_exec_runtime = b->sum_exec_runtime;
> +static void update_gt_cputime(struct thread_group_cputimer *cputimer, struct task_cputime *sum)
> +{
> + __update_gt_cputime(&cputimer->utime, sum->utime);
> + __update_gt_cputime(&cputimer->stime, sum->stime);
> + __update_gt_cputime(&cputimer->sum_exec_runtime, sum->sum_exec_runtime);
> }
And this is called if !cputimer_running().
So who else can update these atomic64_t's ? The caller is called under ->siglock.
IOW, do we really need to cmpxchg/retry ?
Just curious, I am sure I missed something.
> @@ -222,13 +239,10 @@ void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times)
> * it.
> */
> thread_group_cputime(tsk, &sum);
> - raw_spin_lock_irqsave(&cputimer->lock, flags);
> - cputimer->running = 1;
> - update_gt_cputime(&cputimer->cputime, &sum);
> - } else
> - raw_spin_lock_irqsave(&cputimer->lock, flags);
> - *times = cputimer->cputime;
> - raw_spin_unlock_irqrestore(&cputimer->lock, flags);
> + update_gt_cputime(cputimer, &sum);
> + ACCESS_ONCE(cputimer->running) = 1;
WRITE_ONCE() looks better... but it is not clear to me why do we need it
at all.
Oleg.
next prev parent reply other threads:[~2015-03-02 19:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-02 18:42 [PATCH v2] sched, timer: Use atomics for thread_group_cputimer to improve scalability Jason Low
2015-03-02 19:03 ` Linus Torvalds
2015-03-02 21:49 ` Jason Low
2015-03-19 17:21 ` Jason Low
2015-03-19 17:59 ` Linus Torvalds
2015-03-19 20:14 ` Jason Low
2015-03-02 19:40 ` Oleg Nesterov [this message]
2015-03-02 19:43 ` Oleg Nesterov
2015-03-02 21:16 ` Jason Low
2015-03-02 21:44 ` Linus Torvalds
2015-03-02 22:43 ` Jason Low
2015-03-05 15:20 ` Frederic Weisbecker
2015-03-05 20:02 ` Jason Low
2015-03-02 21:19 ` Jason Low
2015-03-05 15:35 ` Frederic Weisbecker
2015-03-05 15:56 ` Paul E. McKenney
2015-03-05 16:00 ` Frederic Weisbecker
2015-03-05 16:16 ` Paul E. McKenney
2015-03-06 0:06 ` Jason Low
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302194033.GA27914@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=fweisbec@gmail.com \
--cc=jason.low2@hp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=scott.norton@hp.com \
--cc=torvalds@linux-foundation.org \
--cc=umgwanakikbuti@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.