All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mike Galbraith <efault@gmx.de>,
	Arjan van de Ven <arjan@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	pranith-kumar_d@mentorg.com, Andi Kleen <andi@firstfloor.org>
Subject: Re: [patch] CFS scheduler, -v14
Date: Thu, 24 May 2007 10:09:59 +0200	[thread overview]
Message-ID: <20070524080959.GA29151@elte.hu> (raw)
In-Reply-To: <20070524064235.GA2386@linux.vnet.ibm.com>


* Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> Hi, Ingo,
> 
> I've implemented a patch on top of v14 for better accounting of 
> sched_info statistics. Earlier, sched_info relied on jiffies for 
> accounting and I've seen applications that show "0" cpu usage 
> statistics (in delay accounting and from /proc) even though they've 
> been running on the CPU for a long time. The basic problem is that 
> accounting in jiffies is too coarse to be accurate.
> 
> The patch below uses sched_clock() for sched_info accounting.

nice! I've merged your patch and it built/booted fine so it should show 
up in -v15. This should also play well with Andi's sched_clock() 
enhancements in -mm, slated for .23.

btw., i think some more consolidation could be done in this area. We've 
now got the traditional /proc/PID/stat metrics, schedstats, taskstats 
and delay accounting and with CFS we've got /proc/sched_debug and 
/proc/PID/sched. There's a fair amount of overlap.

btw., CFS does this change to fs/proc/array.c:

@@ -410,6 +408,14 @@ static int do_task_stat(struct task_stru
 	/* convert nsec -> ticks */
 	start_time = nsec_to_clock_t(start_time);
 
+	/*
+	 * Use CFS's precise accounting, if available:
+	 */
+	if (!has_rt_policy(task)) {
+		utime = nsec_to_clock_t(task->sum_exec_runtime);
+		stime = 0;
+	}
+
 	res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
 %lu %lu %lu %lu %lu %ld %ld %ld %ld %d 0 %llu %lu %ld %lu %lu %lu %lu %lu \
 %lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu %llu\n",

if you have some spare capacity to improve this code, it could be 
further enhanced by not setting 'stime' to zero, but using the existing 
jiffies based utime/stime statistics as a _ratio_ to split up the 
precise p->sum_exec_runtime. That way we dont have to add precise 
accounting to syscall entry/exit points (that would be quite expensive), 
but still the sum of utime+stime would be very precise. (and that's what 
matters most anyway)

	Ingo

  reply	other threads:[~2007-05-24  8:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-23 12:06 [patch] CFS scheduler, -v14 Ingo Molnar
2007-05-23 19:39 ` Nicolas Mailhot
2007-05-23 19:57   ` Ingo Molnar
2007-05-23 20:02     ` Nicolas Mailhot
2007-05-24  6:42 ` Balbir Singh
2007-05-24  8:09   ` Ingo Molnar [this message]
2007-05-24  9:19     ` Balbir Singh
2007-05-24 17:25     ` Jeremy Fitzhardinge
2007-05-24 20:59       ` Ingo Molnar
2007-05-24 22:43         ` Jeremy Fitzhardinge
2007-05-25 12:46     ` Ingo Molnar
2007-05-25 16:45       ` Balbir Singh
2007-05-28 11:07         ` Ingo Molnar
2007-05-29 10:23           ` Balbir Singh
2007-06-05  7:57             ` Ingo Molnar
2007-05-29 10:19       ` Balbir Singh
2007-05-26 14:58 ` S.Çağlar Onur
2007-05-26 15:08   ` S.Çağlar Onur
2007-06-01 13:35   ` S.Çağlar Onur
2007-06-01 15:31     ` Linus Torvalds
2007-06-07 22:29       ` S.Çağlar Onur
2007-06-01 15:37     ` [OT] " Andreas Mohr
2007-05-27  2:49 ` Li Yu
2007-05-29  6:15   ` Ingo Molnar
2007-05-29  8:07     ` Ingo Molnar
2007-05-31  9:45       ` Li Yu
2007-05-31  9:53         ` Ingo Molnar
2007-06-01  7:16           ` Li Yu
2007-06-01 19:21             ` Ingo Molnar
2007-06-05  2:33               ` Li Yu
2007-06-05  8:01                 ` Ingo Molnar
2007-06-05  8:54                   ` Li Yu
2007-06-06  7:41                   ` Li Yu
2007-06-05  3:35               ` Li Yu
2007-05-28  1:17 ` Li Yu
2007-05-29  0:49   ` Li Yu

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=20070524080959.GA29151@elte.hu \
    --to=mingo@elte.hu \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=arjan@infradead.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pranith-kumar_d@mentorg.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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.