top's CPUn vs C column

Chris Ross cross+freebsd at distal.com
Sun Mar 10 02:29:18 UTC 2013


  That patch does in fact work, and removes the inconsistency that I
noted earlier.  I would be happy to see it committed.  If no one else
has objections, please do.

  Thanks...

                                - Chris

On Mar 4, 2013, at 11:37 , John Baldwin <jhb at freebsd.org> wrote:
> On Friday, March 01, 2013 1:17:41 pm Chris Ross wrote:
>> 
>>  So, I was looking at a v240 I have running stable/9 (9.1-STABLE), and 
>> noticed something odd.  The per-CPU information displayed by top seems 
>> inconsistent.  To simplify things, while I'm running a "make release" in 
>> /usr/src/release, I just started running the following command over and over 
>> (by hand):
>> 
>> cross: top | grep " CPU"
>> cross: top | grep " CPU"
>> 1044 cross         1  72    0 17128K  4464K CPU1    0   0:01  1.27% zsh
>> 22528 root          1  77    5 11672K  2592K CPU1    1   0:00  0.00% sh
>> cross: top | grep " CPU"
>> cross: top | grep " CPU"
>> 22634 cross         1  72    0 12808K  2872K CPU1    1   0:00  0.00% top
>> 22633 root          1  77    5  6272K   880K CPU0    1   0:00  0.00% make
>> cross: top | grep " CPU"
>> 22637 root          1  77    5  6272K  1656K CPU0    0   0:00  0.00% make
>> cross: top | grep " CPU"
>> cross: top | grep " CPU"
>> 22684 root          1  77    5 11672K  2592K CPU0    0   0:00  0.00% sh
>> cross:
>> 
>>  This displayed what I had earlier seen in the full-screen top.  There 
>> doesn't appear to be any specific binding between the "n" in the "CPUn" state 
>> value, and the number in the "C" column, which is according to the man page, 
>> should mean the same thing.
>> 
> No, they are different things.  The man page is a bit stale.  The 'C' column 
> is the CPU that the process last ran on.  Hmm, it's actually easiest to fix 
> the code I think.  Try this (untested) change:
> 
> Index: usr.bin/top/machine.c
> ===================================================================
> --- machine.c	(revision 247792)
> +++ machine.c	(working copy)
> @@ -797,7 +797,7 @@ format_next_process(caddr_t handle, char *(*get_us
> 	double pct;
> 	struct handle *hp;
> 	char status[16];
> -	int state;
> +	int cpu, state;
> 	struct rusage ru, *rup;
> 	long p_tot, s_tot;
> 	char *proc_fmt, thr_buf[6], jid_buf[6];
> @@ -997,6 +997,13 @@ format_next_process(caddr_t handle, char *(*get_us
> 	}
> 
> 	/* format this entry */
> +	if (smpmode) {
> +		if (state == SRUN && pp->ki_oncpu != 0xff)
> +			cpu = pp->ki_oncpu;
> +		else
> +			cpu = pp->ki_lastcpu;
> +	} else
> +		cpu = 0;
> 	proc_fmt = smpmode ? smp_Proc_format : up_Proc_format;
> 	if (ps.thread != 0)
> 		thr_buf[0] = '\0';
> @@ -1014,7 +1021,7 @@ format_next_process(caddr_t handle, char *(*get_us
> 	    format_k2(PROCSIZE(pp)),
> 	    format_k2(pagetok(pp->ki_rssize)),
> 	    status,
> -	    smpmode ? pp->ki_lastcpu : 0,
> +	    cpu,
> 	    format_time(cputime),
> 	    ps.wcpu ? 100.0 * weighted_cpu(pct, pp) : 100.0 * pct,
> 	    screen_width > cmdlengthdelta ? screen_width - cmdlengthdelta : 0,
> 
> -- 
> John Baldwin



More information about the freebsd-sparc64 mailing list