linux-kernel - Re: getting processor numbers

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]

Message-ID: <20070403194058.GD355@devserv.devel.redhat.com>
Date:	Tue, 3 Apr 2007 15:40:58 -0400
From:	Jakub Jelinek <jakub@...hat.com>
To:	Ulrich Drepper <drepper@...hat.com>
Cc:	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: getting processor numbers

On Tue, Apr 03, 2007 at 10:59:53AM -0700, Ulrich Drepper wrote:
> Siddha, Suresh B wrote:
> > Not all of the cpu* directories in /sys/devices/system/cpu may be
> > online.
> 
> Brilliant.  You people really know how to create user interfaces.  So
> now in any case per CPU another stat/access syscall is needed to check
> the 'online' pseudo-file?  With this the readdir solution is only
> marginally faster than parsing /proc/cpuinfo which means, it's
> unacceptably slow.

Note that glibc actually parses /proc/stat in preference of /proc/cpuinfo
ATM, because /proc/stat is at least uniform while parsing /proc/cpuinfo
needs a special parser for each architecture.  And /proc/stat reading
is even slower than /proc/cpuinfo, on x86_64 reading/parsing /proc/stat
takes about 450usec, while e.g. stat64 on /sys/devices/system/cpu
is just 2.5usec.
But if that can't be trusted as the number of online CPUs, can
somebody please add a short file to proc or sysfs which will contain
the number of online and number of configured CPUs?

See e.g. http://openmp.org/pipermail/omp/2007/000714.html
where the first time after second g++ invocation is with omp_set_dynamic (1)
and ought to be about as fast as omp_set_dynamic (0) case with the same
number of threads, but it is far slower due to slow
sysconf (_SC_NPROCESSORS_ONLN).

	Jakub
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/