From: Rik van Riel <riel@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: Wanpeng Li <kernellwp@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Luiz Capitulino <lcapitulino@redhat.com>,
Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource
Date: Thu, 29 Jun 2017 19:27:27 -0400 [thread overview]
Message-ID: <1498778847.6130.8.camel@redhat.com> (raw)
In-Reply-To: <1498756511-11714-6-git-send-email-fweisbec@gmail.com>
On Thu, 2017-06-29 at 19:15 +0200, Frederic Weisbecker wrote:
> From: Wanpeng Li <kernellwp@gmail.com>
>
> Currently the cputime source used by vtime is jiffies. When we cross
> a context boundary and jiffies have changed since the last snapshot,
> the
> pending cputime is accounted to the switching out context.
>
> This system works ok if the ticks are not aligned across CPUs. If
> they
> instead are aligned (ie: all fire at the same time) and the CPUs run
> in
> userspace, the jiffies change is only observed on tick exit and
> therefore
> the user cputime is accounted as system cputime. This is because the
> CPU that maintains timekeeping fires its tick at the same time as the
> others. It updates jiffies in the middle of the tick and the other
> CPUs
> see that update on IRQ exit:
>
> CPU 0 (timekeeper) CPU 1
> ------------------- -------------
> jiffies = N
> ... run in userspace for a jiffy
> tick entry tick entry (sees jiffies = N)
> set jiffies = N + 1
> tick exit tick exit (sees jiffies = N + 1)
> account 1 jiffy as
> stime
>
> Fix this with using a nanosec clock source instead of jiffies. The
> cputime is then accumulated and flushed everytime the pending delta
> reaches a jiffy in order to mitigate the accounting overhead.
Glad to hear this could be done without dramatically
increasing the accounting overhead!
> [fweisbec: changelog, rebase on struct vtime, field renames, add
> delta
> on cputime readers, keep idle vtime as-is (low overhead accounting),
> harmonize clock sources]
>
> Reported-by: Luiz Capitulino <lcapitulino@redhat.com>
> Suggested-by: Thomas Gleixner <tglx@linutronix.de>
> Not-Yet-Signed-off-by: Wanpeng Li <kernellwp@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Wanpeng Li <kernellwp@gmail.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Luiz Capitulino <lcapitulino@redhat.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Rik van Riel <riel@redhat.com>
next prev parent reply other threads:[~2017-06-29 23:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 17:15 [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting Frederic Weisbecker
2017-06-29 17:15 ` [PATCH 1/5] vtime: Remove vtime_account_user() Frederic Weisbecker
2017-06-29 23:01 ` Rik van Riel
2017-07-05 10:28 ` [tip:sched/urgent] vtime, sched/cputime: " tip-bot for Frederic Weisbecker
2017-06-29 17:15 ` [PATCH 2/5] sched: Always set vtime_snap_whence after accounting vtime Frederic Weisbecker
2017-06-29 23:01 ` Rik van Riel
2017-07-05 10:28 ` [tip:sched/urgent] sched/cputime: Always set tsk->vtime_snap_whence " tip-bot for Frederic Weisbecker
2017-06-29 17:15 ` [PATCH 3/5] sched: Rename vtime fields Frederic Weisbecker
2017-06-29 23:02 ` Rik van Riel
2017-07-05 10:28 ` [tip:sched/urgent] sched/cputime: " tip-bot for Frederic Weisbecker
2017-06-29 17:15 ` [PATCH 4/5] sched: Move vtime task fields to their own struct Frederic Weisbecker
2017-06-29 23:05 ` Rik van Riel
2017-07-05 10:29 ` [tip:sched/urgent] sched/cputime: Move the " tip-bot for Frederic Weisbecker
2017-06-29 17:15 ` [PATCH 5/5] sched: Accumulate vtime on top of nsec clocksource Frederic Weisbecker
2017-06-29 23:27 ` Rik van Riel [this message]
2017-07-05 13:20 ` Frederic Weisbecker
2017-06-30 1:52 ` Wanpeng Li
2017-07-05 10:29 ` [tip:sched/urgent] sched/cputime: " tip-bot for Wanpeng Li
2017-07-15 3:37 ` [PATCH 5/5] sched: " Levin, Alexander (Sasha Levin)
2017-07-15 5:26 ` Wanpeng Li
2017-06-30 1:41 ` [RFC PATCH 0/5] vtime: Fix wrong user and system time accounting Wanpeng Li
2017-06-30 17:32 ` Luiz Capitulino
2017-07-03 10:28 ` Thomas Gleixner
2017-07-04 16:52 ` Luiz Capitulino
2017-07-05 13:16 ` Frederic Weisbecker
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=1498778847.6130.8.camel@redhat.com \
--to=riel@redhat.com \
--cc=fweisbec@gmail.com \
--cc=kernellwp@gmail.com \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--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.