Skip to contentSkip to conversation

shrink task_struct by removing per_cpu utime and stime

RFC In review William Lee Irwin III 2 participants 5 messages Jul 16, 2002

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

RFC 1/1 shrink task_struct by removing per_cpu utime and stime

These statistics severely bloat the task_struct and nothing in userspace can rely on them as they're conditional on CONFIG_SMP. If anyone is using them (or just wants them around), please speak up.

Cheers,
Bill

===== fs/proc/array.c 1.24 vs edited =====

fs/proc/array.c +0 -22
@@ -685,25 +685,3 @@
 out:
 	return retval;
 }
-
-#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]));
-
-	}
-	return len;
-}
-#endif

===== fs/proc/base.c 1.26 vs edited =====

fs/proc/base.c +1 -10
@@ -52,7 +52,6 @@
 	PROC_PID_STAT,
 	PROC_PID_STATM,
 	PROC_PID_MAPS,
-	PROC_PID_CPU,
 	PROC_PID_MOUNTS,
 	PROC_PID_FD_DIR = 0x8000,	/* 0x8000-0xffff */
 };
@@ -72,9 +71,6 @@
   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),
@@ -1010,12 +1006,7 @@
 		case PROC_PID_MAPS:
 			inode->i_fop = &proc_maps_operations;
 			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_MEM:
 			inode->i_op = &proc_mem_inode_operations;
 			inode->i_fop = &proc_mem_operations;

===== include/linux/sched.h 1.70 vs edited =====

include/linux/sched.h +0 -1
@@ -311,7 +311,6 @@
 	struct timer_list real_timer;
 	unsigned long utime, stime, cutime, cstime;
 	unsigned long start_time;
-	long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
 /* 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;
 	int swappable:1;

===== kernel/fork.c 1.49 vs edited =====

kernel/fork.c +1 -10
@@ -688,16 +688,7 @@
 	p->tty_old_pgrp = 0;
 	p->utime = p->stime = 0;
 	p->cutime = p->cstime = 0;
-#ifdef CONFIG_SMP
-	{
-		int i;
-
-		/* ?? should we just memset this ?? */
-		for(i = 0; i < NR_CPUS; i++)
-			p->per_cpu_utime[i] = p->per_cpu_stime[i] = 0;
-		spin_lock_init(&p->sigmask_lock);
-	}
-#endif
+	spin_lock_init(&p->sigmask_lock);
 	p->array = NULL;
 	p->lock_depth = -1;		/* -1 = no lock */
 	p->start_time = jiffies;

===== kernel/timer.c 1.17 vs edited =====

kernel/timer.c +0 -2
@@ -569,8 +569,6 @@
 void update_one_process(struct task_struct *p, unsigned long user,
 			unsigned long system, int cpu)
 {
-	p->per_cpu_utime[cpu] += user;
-	p->per_cpu_stime[cpu] += system;
 	do_process_times(p, user, system);
 	do_it_virt(p, user);
 	do_it_prof(p);
#1 lore raw
Quoted 3 lines · William Lee Irwin III

These statistics severely bloat the task_struct and nothing in userspace can rely on them as they're conditional on CONFIG_SMP. If anyone is using them (or just wants them around), please speak up.

User space can rely on them because it can check if the data is present. Some of the graphical process monitors dump per cpu utime/stime. Its sometimes a good way to cringe at our SMP balancing algorithms in 2.4

#2 lore raw
Quoted 3 lines · William Lee Irwin III
Quoted 3 lines

These statistics severely bloat the task_struct and nothing in userspace can rely on them as they're conditional on CONFIG_SMP. If anyone is using them (or just wants them around), please speak up.

Quoted 3 lines · Alan Cox

User space can rely on them because it can check if the data is present. Some of the graphical process monitors dump per cpu utime/stime. Its sometimes a good way to cringe at our SMP balancing algorithms in 2.4

If that's a "no" I can deal with it. I'm just cringing at its space consumption and I guess we all know how oversensitive I am to that =).

Cheers,
Bill

#4 lore raw
Quoted 2 lines · Alan Cox

A PS: to that. I'm not opposed to removing them. I'd prefer them left around in the kernel debugging options though

In that case, I can make it conditional on something like CONFIG_DEBUG_SCHED, which option of course would go in the "Kernel Hacking" section.

Cheers,
Bill