shrink task_struct by removing per_cpu utime and stime
Subsystems (4)
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 ), -#endifE (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);
Quoted 3 lines · William Lee Irwin III
These statistics severely bloat the
task_structand nothing in userspace can rely on them as they're conditional onCONFIG_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
Quoted 3 lines · William Lee Irwin III
Quoted 3 lines
These statistics severely bloat the
task_structand nothing in userspace can rely on them as they're conditional onCONFIG_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
A PS: to that. I'm not opposed to removing them. I'd prefer them left around in the kernel debugging options though
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