• jim warner's avatar
    top: improve logic surrounding 'smp_num_cpus' variable · 893793a8
    jim warner authored
    I thank Guido Jäkel for raising the issue cited in the
    merge request referenced below. While restoring 1 line
    of code would produce the desired results, it does not
    address the root cause of that problem he experienced.
    
    The variable 'smp_num_cpus' was set by libprocps via a
    sysconf(_SC_NPROCESSORS_ONLN) call. It was supposed to
    represent total number of processors currently online.
    It also served as the position in the Cpu_tics[] array
    where the /proc/stat line #1 (cpu summary) was stored.
    
    The variable 'Cpu_faux_tot' was valued by top based on
    total individual cpus parsed from the /proc/stat file.
    It serves as a fence post for Cpu_tics[] array access.
    
    The problem Guido experienced results from a disparity
    between those 2 variables, plus one instance where the
    wrong variable was used in the summary_show() routine.
    
    . Here is the real culprit, the actual incorrect code:
    . summary_hlp(&Cpu_tics[Cpu_faux_tot], N_txt(WORD_a...
    
    Which always should have been represented in this way:
    . summary_hlp(&Cpu_tics[smp_num_cpus], N_txt(WORD_a...
    
    ------------------------------------------------------
    The above 'disparity' might arise in any system when a
    cpu is taken offline since there's a 3 second delay in
    cpu and memory refreshes in an effort to reduce costs.
    Usually this particular condition will be short lived.
    
    However, there is a more persistent problem under lxc.
    
    If a host cpu is taken offline and then brought online
    again, within the container sysconf returns the proper
    number of online processors. But, /proc/stat does not!
    Sadly, I've yet to find a way to coax a container into
    refreshing its /proc/stat, short of reboting the host.
    
    [ might that represent a potential bug in lxc logic? ]
    
    Reference(s):
    !82Signed-off-by: jim warner's avatarJim Warner <james.warner@comcast.net>
    With-thanks-to: Guido Jäkel <G.Jaekel@DNB.DE>
    893793a8
top.c 227 KB