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