All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xie XiuQi <xiexiuqi@huawei.com>
To: Mike Galbraith <efault@gmx.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Ingo Molnar <mingo@elte.hu>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>, Li Zefan <lizefan@huawei.com>,
	Zhang Hang <bob.zhanghang@huawei.com>,
	Li Bin <huawei.libin@huawei.com>
Subject: [PATCH] sched: fix cpu utilization account error
Date: Mon, 1 Jul 2013 14:45:04 +0800	[thread overview]
Message-ID: <51D12570.9070100@huawei.com> (raw)

We setting clock_skip_update = 1 based on the assumption that the
next call to update_rq_clock() will come nearly immediately
after being set. However, it is not always true especially on
non-preempt mode. In this case we may miss some clock update, which
would cause an error curr->sum_exec_runtime account.

The test result show that test_kthread's exec_runtime has been
added to watchdog.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+   P COMMAND
   28 root      RT   0     0    0    0 S  100  0.0   0:05.39  5 watchdog/5
    7 root      RT   0     0    0    0 S   95  0.0   0:05.83  0 watchdog/0
   12 root      RT   0     0    0    0 S   94  0.0   0:05.79  1 watchdog/1
   16 root      RT   0     0    0    0 S   92  0.0   0:05.74  2 watchdog/2
   20 root      RT   0     0    0    0 S   91  0.0   0:05.71  3 watchdog/3
   24 root      RT   0     0    0    0 S   82  0.0   0:05.42  4 watchdog/4
   32 root      RT   0     0    0    0 S   79  0.0   0:05.35  6 watchdog/6
 5200 root      20   0     0    0    0 R   21  0.0   0:08.88  6 test_kthread/6
 5194 root      20   0     0    0    0 R   20  0.0   0:08.41  0 test_kthread/0
 5195 root      20   0     0    0    0 R   20  0.0   0:08.44  1 test_kthread/1
 5196 root      20   0     0    0    0 R   20  0.0   0:08.49  2 test_kthread/2
 5197 root      20   0     0    0    0 R   20  0.0   0:08.53  3 test_kthread/3
 5198 root      20   0     0    0    0 R   19  0.0   0:08.81  4 test_kthread/4
 5199 root      20   0     0    0    0 R    2  0.0   0:08.66  5 test_kthread/5

"test_kthread/i" is a kernel thread which has a infinity loop and it calls
schedule() every 1s. It's main process as below:

static int main_loop (void *unused)
{
	unsigned long flags;
	unsigned long last = jiffies;
	int i;

	while (!kthread_should_stop()) {
		/* call schedule every 1 sec */
		if (HZ <= jiffies - last) {
			last = jiffies;
			schedule();
		}

		/* do some thing */
		for (i = 0; i < 1000; i++)
		;

		if (kthread_should_stop())
			break;
	}
}

In this patch, we do not skip clock update when current task is kernel
thread in non-preempt mode.

Reported-by: Zhang Hang <bob.zhanghang@huawei.com>
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com>
---
 kernel/sched/core.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index e8b3350..018dc43 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -970,8 +970,19 @@ void check_preempt_curr(struct rq *rq, struct task_struct *p, int flags)
 	 * A queue event has occurred, and we're going to schedule.  In
 	 * this case, we can save a useless back to back clock update.
 	 */
+#ifdef CONFIG_PREEMPT
 	if (rq->curr->on_rq && test_tsk_need_resched(rq->curr))
 		rq->skip_clock_update = 1;
+#else
+	/*
+	 * In non-preempt mode, a kernel thread may run for a long time
+	 * until been scheduled out by itself. In this cace, we need update
+	 * rq clock when calling schedule function, otherwise, we might
+	 * miss rq clock update for a long time.
+	 */
+	if (rq->curr->on_rq && test_tsk_need_resched(rq->curr) && rq->curr->mm)
+		rq->skip_clock_update = 1;
+#endif
 }

 static ATOMIC_NOTIFIER_HEAD(task_migration_notifier);
-- 
1.7.6.1


             reply	other threads:[~2013-07-01  6:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01  6:45 Xie XiuQi [this message]
2013-07-01  7:36 ` [PATCH] sched: fix cpu utilization account error Mike Galbraith
2013-07-01 11:26   ` Xie XiuQi
2013-07-01 11:43     ` Mike Galbraith
2013-07-02  3:07     ` Mike Galbraith
2013-07-02  4:11       ` Xie XiuQi
2013-07-02  3:20     ` Michael Wang
2013-07-02  4:15       ` Xie XiuQi
2013-07-01 15:19 ` Greg KH
2013-07-02  1:41   ` Xie XiuQi

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=51D12570.9070100@huawei.com \
    --to=xiexiuqi@huawei.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bob.zhanghang@huawei.com \
    --cc=efault@gmx.de \
    --cc=huawei.libin@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mingo@elte.hu \
    --cc=stable@vger.kernel.org \
    /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.