All of lore.kernel.org
 help / color / mirror / Atom feed
From: <shai@ftcon.com>
To: "'Andrew Morton'" <akpm@osdl.org>
Cc: <ricklind@us.ibm.com>, <mbligh@aracnet.com>,
	<lse-tech@lists.sourceforge.net>,
	"'Erik Jacobson'" <erikj@subway.americas.sgi.com>,
	"'Erich Focht'" <efocht@hpce.nec.com>,
	"'Paul Jackson'" <pj@sgi.com>,
	"'Xavier Bru'" <xavier.bru@bull.net>,
	<linux-kernel@vger.kernel.org>
Subject: FW: [Lse-tech] Re: NUMA scheduler issue
Date: Sun, 28 Mar 2004 02:07:54 -0800	[thread overview]
Message-ID: <200403281007.BHM58439@ms6.netsolmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

Hi,

Very nice patch.
Andrew, would you consider adding this one? 

--Shai


-----Original Message-----
From: lse-tech-admin@lists.sourceforge.net
[mailto:lse-tech-admin@lists.sourceforge.net] On Behalf Of Erich Focht
Sent: Friday, March 26, 2004 00:31
To: Paul Jackson; Xavier Bru
Cc: ricklind@us.ibm.com; mbligh@aracnet.com; lse-tech@lists.sourceforge.net;
Erik Jacobson
Subject: Re: [Lse-tech] Re: NUMA scheduler issue

Hi Paul,

On Wednesday 24 March 2004 20:03, Paul Jackson wrote:
> Where are you getting the printouts that look like:
>
>     initial CPU = 2
>     cpu  18491 16
>     cpu0 17125 2
>     cpu1 441 0
>     cpu2 700 14
>     cpu3 225 0
>     ...
>     current_cpu 0
>
> We have something in our SGI 2.4 kernels (/proc/<pid>/cpu) that
> displays this sort of per-cpu usage, but I don't see anything
> in the 2.6 kernels that seems to do this.

its probably the attached patch. Sorry, I'm travelling and couldn't
rediff against a current version...





[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cputimes_stat-2.6.0t1.patch --]
[-- Type: text/x-diff; name="cputimes_stat-2.6.0t1.patch", Size: 3895 bytes --]

diff -urN 2.6.0-test1-ia64-0/fs/proc/array.c 2.6.0-test1-ia64-na/fs/proc/array.c
--- 2.6.0-test1-ia64-0/fs/proc/array.c	2003-07-14 05:35:12.000000000 +0200
+++ 2.6.0-test1-ia64-na/fs/proc/array.c	2003-07-18 13:38:02.000000000 +0200
@@ -405,3 +405,26 @@
 	return sprintf(buffer,"%d %d %d %d %d %d %d\n",
 		       size, resident, shared, text, lib, data, 0);
 }
+
+#ifdef CONFIG_SMP
+int proc_pid_cpu(struct task_struct *task, char * buffer)
+{
+	int i, len;
+
+	len = sprintf(buffer,
+		"cpu  %lu %lu\n",
+		jiffies_to_clock_t(task->utime),
+		jiffies_to_clock_t(task->stime));
+		
+	for (i = 0 ; i < NR_CPUS; i++) {
+		if (cpu_online(i))
+		len += sprintf(buffer + len, "cpu%d %lu %lu\n",
+			i,
+			jiffies_to_clock_t(task->per_cpu_utime[i]),
+			jiffies_to_clock_t(task->per_cpu_stime[i]));
+
+	}
+	len += sprintf(buffer + len, "current_cpu %d\n",task_cpu(task));
+	return len;
+}
+#endif
diff -urN 2.6.0-test1-ia64-0/fs/proc/base.c 2.6.0-test1-ia64-na/fs/proc/base.c
--- 2.6.0-test1-ia64-0/fs/proc/base.c	2003-07-14 05:35:15.000000000 +0200
+++ 2.6.0-test1-ia64-na/fs/proc/base.c	2003-07-18 13:38:02.000000000 +0200
@@ -56,6 +56,7 @@
 	PROC_PID_STAT,
 	PROC_PID_STATM,
 	PROC_PID_MAPS,
+	PROC_PID_CPU,
 	PROC_PID_MOUNTS,
 	PROC_PID_WCHAN,
 #ifdef CONFIG_SECURITY
@@ -83,6 +84,9 @@
   E(PROC_PID_CMDLINE,	"cmdline",	S_IFREG|S_IRUGO),
   E(PROC_PID_STAT,	"stat",		S_IFREG|S_IRUGO),
   E(PROC_PID_STATM,	"statm",	S_IFREG|S_IRUGO),
+#ifdef CONFIG_SMP
+  E(PROC_PID_CPU,	"cpu",		S_IFREG|S_IRUGO),
+#endif
   E(PROC_PID_MAPS,	"maps",		S_IFREG|S_IRUGO),
   E(PROC_PID_MEM,	"mem",		S_IFREG|S_IRUSR|S_IWUSR),
   E(PROC_PID_CWD,	"cwd",		S_IFLNK|S_IRWXUGO),
@@ -1170,6 +1174,12 @@
 			inode->i_fop = &proc_info_file_operations;
 			ei->op.proc_read = proc_pid_stat;
 			break;
+#ifdef CONFIG_SMP
+		case PROC_PID_CPU:
+			inode->i_fop = &proc_info_file_operations;
+			ei->op.proc_read = proc_pid_cpu;
+			break;
+#endif
 		case PROC_PID_CMDLINE:
 			inode->i_fop = &proc_info_file_operations;
 			ei->op.proc_read = proc_pid_cmdline;
diff -urN 2.6.0-test1-ia64-0/include/linux/sched.h 2.6.0-test1-ia64-na/include/linux/sched.h
--- 2.6.0-test1-ia64-0/include/linux/sched.h	2003-07-14 05:30:40.000000000 +0200
+++ 2.6.0-test1-ia64-na/include/linux/sched.h	2003-07-18 13:38:02.000000000 +0200
@@ -390,6 +390,9 @@
 	struct list_head posix_timers; /* POSIX.1b Interval Timers */
 	unsigned long utime, stime, cutime, cstime;
 	u64 start_time;
+#ifdef CONFIG_SMP
+	long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
+#endif
 /* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
 	unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
 /* process credentials */
diff -urN 2.6.0-test1-ia64-0/kernel/fork.c 2.6.0-test1-ia64-na/kernel/fork.c
--- 2.6.0-test1-ia64-0/kernel/fork.c	2003-07-14 05:30:39.000000000 +0200
+++ 2.6.0-test1-ia64-na/kernel/fork.c	2003-07-18 13:38:02.000000000 +0200
@@ -861,6 +861,14 @@
 	p->tty_old_pgrp = 0;
 	p->utime = p->stime = 0;
 	p->cutime = p->cstime = 0;
+#ifdef CONFIG_SMP
+	{
+		int i;
+
+		for(i = 0; i < NR_CPUS; i++)
+			p->per_cpu_utime[i] = p->per_cpu_stime[i] = 0;
+	}
+#endif
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = get_jiffies_64();
diff -urN 2.6.0-test1-ia64-0/kernel/timer.c 2.6.0-test1-ia64-na/kernel/timer.c
--- 2.6.0-test1-ia64-0/kernel/timer.c	2003-07-14 05:37:22.000000000 +0200
+++ 2.6.0-test1-ia64-na/kernel/timer.c	2003-07-18 13:38:02.000000000 +0200
@@ -720,6 +720,10 @@
 void update_one_process(struct task_struct *p, unsigned long user,
 			unsigned long system, int cpu)
 {
+#ifdef CONFIG_SMP
+	p->per_cpu_utime[cpu] += user;
+	p->per_cpu_stime[cpu] += system;
+#endif
 	do_process_times(p, user, system);
 	do_it_virt(p, user);
 	do_it_prof(p);

             reply	other threads:[~2004-03-28 10:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-28 10:07 shai [this message]
2004-03-28 10:21 ` FW: [Lse-tech] Re: NUMA scheduler issue Andrew Morton

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=200403281007.BHM58439@ms6.netsolmail.com \
    --to=shai@ftcon.com \
    --cc=akpm@osdl.org \
    --cc=efocht@hpce.nec.com \
    --cc=erikj@subway.americas.sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=mbligh@aracnet.com \
    --cc=pj@sgi.com \
    --cc=ricklind@us.ibm.com \
    --cc=xavier.bru@bull.net \
    /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.