linux-kernel - RE: Regression in reading /proc/stat in the newer kernels with large SMP and NUMA configurations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Oct 2011 18:02:16 +0100
From:	"Oberman, Laurence (HAS GSE)" <Laurence.Oberman@...com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"Seger, Mark" <mark.seger@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Cabaniols, Sebastien" <Sebastien.Cabaniols@...com>
Subject: RE: Regression in reading /proc/stat in the newer kernels with
 large SMP and NUMA configurations

Hi Eric,

Just FYI, the same behavior is seen on multiple hardware platforms so it is definitely kernel changes. The earlier kernel on the DL785 platform was returning reads within 60 microseconds.
I have measured it on multiple platforms.

In this case we have a DL980 with HT enabled so you will see 128 CPUS. If I shut off HT, it does not make a difference.

[root@...uxbeast boot]# dmesg | grep nr_cpu_ids
NR_CPUS:4096 nr_cpumask_bits:128 nr_cpu_ids:128 nr_node_ids:8

-----Original Message-----
From: Eric Dumazet [mailto:eric.dumazet@...il.com] 
Sent: Friday, October 14, 2011 12:59 PM
To: Oberman, Laurence (HAS GSE)
Cc: Seger, Mark; linux-kernel@...r.kernel.org; Cabaniols, Sebastien
Subject: RE: Regression in reading /proc/stat in the newer kernels with large SMP and NUMA configurations

Le vendredi 14 octobre 2011 à 17:52 +0100, Oberman, Laurence (HAS GSE) a
écrit :
> Standard RHEL kernel build.
> What the customer would be using.
> 
> [root@...uxbeast boot]# cat config-2.6.32-131.6.1.el6.x86_64 | grep NR
> CONFIG_NR_CPUS=4096

Then something must be wrong.... what are your nr_cpu_ids /
nr_cpumask_bits values ?


dmesg | grep nr_cpu_ids