Re: Top does not handle more than 100 cores
On Mon, Mar 24, 2014 at 12:08 PM, Alexandre De Champeaux wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv > uname output: Linux isv 2.6.32-279.el6.x86_64 #1 SMP Wed Jun 13 18:24:36 > EDT 2012 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-redhat-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > The top command does not handle more than 100 cores. I also > attached two screenshots of the issue, one showing the output of the top > command, and the other of a custom script showing the CPU usage per numa > node (the server has 160 cores). > Here is the ouptu of a top -v : > [root@isv ~]# top -v > top: procps version 3.2.8 > > I did not try to reproduce on the latest version of top. > > > Repeat-By: > Find a pretty cool machine with quite a bunch of cores, and run an > highly parallel program :). > > -- > Alexandre > However, top is an external command and has nothing to do with bash, so you need to report this to its authors, or to the package maintainer(s) of your distribution.
Re: Top does not handle more than 100 cores
Alexandre De Champeaux writes: > The top command is not part of bash, and thus off-topic. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
RE: Top does not handle more than 100 cores
Seems that the top command has nothing to do with bash. Sorry about that, and thanks for your fast answers. The bug is however not critical enough for me to spend more time searching for the real authors. Cheers, -- Alexandre
Re: Top does not handle more than 100 cores
Alexandre De Champeaux writes: > Seems that the top command has nothing to do with bash. Sorry about that, > and thanks for your fast answers. The bug is however not critical enough > for me to spend more time searching for the real authors. $ rpm -qif /usr/bin/top | grep URL URL : http://sf.net/projects/procps-ng/ Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Special built-ins not persisting assignments
$ echo $BASH_VERSION 4.2.45(1)-release $ unset foo $ foo=bar : $ echo $foo $ === According to POSIX/SUS issue 7, assignments for special builtins should persist. So the output should be ``bar''. Is there a setting I should turn off (or need to enable), to make this work correctly? I was able to confirm this bug for version 4.2.37(1)-release as well. (zsh 4.3.17 (i386-redhat-linux-gnu) has the same bug.) -- Wayne Pollock
Re: Special built-ins not persisting assignments
On Tue, Mar 25, 2014 at 2:39 AM, Pollock, Wayne wrote: > $ echo $BASH_VERSION > 4.2.45(1)-release > > $ unset foo > > $ foo=bar : > > $ echo $foo > > > $ > > === > > According to POSIX/SUS issue 7, assignments for special builtins > should persist. So the output should be ``bar''. > > Is there a setting I should turn off (or need to enable), to > make this work correctly? > > I was able to confirm this bug for version 4.2.37(1)-release as > well. (zsh 4.3.17 (i386-redhat-linux-gnu) has the same bug.) > > -- > Wayne Pollock It works when bash runs in posix mode, eg: $ POSIXLY_CORRECT=1 bash -c 'foo=bar : ;echo $foo' bar $ bash --posix -c 'foo=bar : ;echo $foo' bar
