From: Frederic Weisbecker <fweisbec@gmail.com>
To: kosaki.motohiro@gmail.com
Cc: linux-kernel@vger.kernel.org,
Olivier Langlois <olivier@trillion01.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: [PATCH 6/8] sched: task_sched_runtime introduce micro optimization
Date: Tue, 18 Jun 2013 16:27:45 +0200 [thread overview]
Message-ID: <20130618142744.GG17619@somewhere.redhat.com> (raw)
In-Reply-To: <1369604149-13016-9-git-send-email-kosaki.motohiro@gmail.com>
On Sun, May 26, 2013 at 05:35:47PM -0400, kosaki.motohiro@gmail.com wrote:
> From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>
> rq lock in task_sched_runtime() is necessary for two reasons. 1)
> accessing se.sum_exec_runtime is not atomic on 32bit and 2)
> do_task_delta_exec() require it.
>
> So, 64bit can avoid holding rq lock when add_delta is false and
> delta_exec is 0.
>
> Cc: Olivier Langlois <olivier@trillion01.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Frederic Weisbecker <fweisbec@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Suggested-by: Paul Turner <pjt@google.com>
> Acked-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> ---
> kernel/sched/core.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 96512e9..0f859cc 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2692,6 +2692,21 @@ unsigned long long task_sched_runtime(struct task_struct *p, bool add_delta)
> struct rq *rq;
> u64 ns = 0;
>
> +#ifdef CONFIG_64BIT
> + /*
> + * 64-bit doesn't need locks to atomically read a 64bit value. So we
> + * have two optimization chances, 1) when caller doesn't need
> + * delta_exec and 2) when the task's delta_exec is 0. The former is
> + * obvious. The latter is complicated. reading ->on_cpu is racy, but
> + * this is ok. If we race with it leaving cpu, we'll take a lock. So
> + * we're correct. If we race with it entering cpu, unaccounted time
> + * is 0. This is indistinguishable from the read occurring a few
> + * cycles earlier.
> + */
> + if (!add_delta || !p->on_cpu)
> + return p->se.sum_exec_runtime;
I'm not sure this is correct from an smp ordering POV. p->on_cpu may appear
to be 0 whereas the task is actually running for a while and p->se.sum_exec_runtime
can then be past the actual value on the remote CPU.
> +#endif
> +
> rq = task_rq_lock(p, &flags);
> ns = p->se.sum_exec_runtime;
> if (add_delta)
> --
> 1.7.1
>
next prev parent reply other threads:[~2013-06-18 14:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-26 21:35 [PATCH v5 0/8] posix timers fixlet kosaki.motohiro
2013-05-26 21:35 ` [PATCH 1/8] posix-cpu-timers: don't account cpu timer after stopped thread runtime accounting kosaki.motohiro
2013-05-26 21:35 ` [PATCH 2/8] posix-cpu-timers: fix acounting delta_exec twice kosaki.motohiro
2013-06-03 19:07 ` Frederic Weisbecker
2013-05-26 21:35 ` kosaki.motohiro
2013-05-26 21:35 ` [PATCH 3/8] posix-cpu-timers: fix wrong timer initialization kosaki.motohiro
2013-06-18 14:20 ` Frederic Weisbecker
2013-06-18 15:12 ` KOSAKI Motohiro
2013-06-19 20:56 ` Frederic Weisbecker
2013-05-26 21:35 ` [PATCH 4/8] posix-cpu-timers: timer functions should use timer time instead of clock time kosaki.motohiro
2013-05-26 21:35 ` [PATCH 5/8] posix-cpu-timers: check_thread_timers() uses task_sched_runtime() kosaki.motohiro
2013-05-26 21:35 ` [PATCH 6/8] sched: task_sched_runtime introduce micro optimization kosaki.motohiro
2013-06-18 14:27 ` Frederic Weisbecker [this message]
2013-06-18 15:17 ` KOSAKI Motohiro
2013-06-18 15:28 ` KOSAKI Motohiro
2013-06-18 17:18 ` Frederic Weisbecker
2013-06-20 8:41 ` KOSAKI Motohiro
2013-05-26 21:35 ` [PATCH 7/8] posix-cpu-timers: cleanup cpu_{clock,timer}_sample{,_group} kosaki.motohiro
2013-05-26 21:35 ` [PATCH 8/8] posix-cpu-timers: fix cputimer initialization mistake for {u,s}time kosaki.motohiro
2013-05-31 16:26 ` [PATCH v5 0/8] posix timers fixlet KOSAKI Motohiro
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=20130618142744.GG17619@somewhere.redhat.com \
--to=fweisbec@gmail.com \
--cc=kosaki.motohiro@gmail.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=olivier@trillion01.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.