From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14050 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mathieu Desnoyers Newsgroups: gmane.linux.lib.musl.general Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Date: Tue, 2 Apr 2019 18:38:18 -0400 (EDT) Message-ID: <1935008937.138.1554244698897.JavaMail.zimbra@efficios.com> References: <20190315210202.GD6994@joraj-alpa> <20190316022534.GN26605@port70.net> <20190326162334.GF17481@joraj-alpa> <20190326174540.GH26605@port70.net> <1391784430.9599.1553623268878.JavaMail.zimbra@efficios.com> <20190402190253.GT26605@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="231640"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl , Michael Jeanson , Richard Purdie , Jonathan Rajotte To: Szabolcs Nagy Original-X-From: musl-return-14066-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 03 00:38:37 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hBS39-000y4f-FY for gllmg-musl@m.gmane.org; Wed, 03 Apr 2019 00:38:35 +0200 Original-Received: (qmail 21832 invoked by uid 550); 2 Apr 2019 22:38:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 21806 invoked from network); 2 Apr 2019 22:38:32 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 2D8A01A11E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1554244699; bh=4NDVGWIwwEFRB3VenhwdwEGWLOHiVPe7w1jiLNLNyPc=; h=Date:From:To:Message-ID:MIME-Version; b=QgNTCbGwER8JHL6x54HbbFdEbCC8bch56Up4BEoTNHW/kwKh852g6Gtn0yI04Nn7R d7FcuttmIKyFpzCkCx68l9KnFfUB0OSVZJ77S5ivEhB9n5wQvUnd8Ebm1/OBzh4TTM q2DP+8jhb2TNU0aveADkFotdNx+4j/guwzSm40Yybzk6qVX1+3Jntn1Muq1Qzkvvs4 lqZ25R0WxDaxyPA97aOtcQx/qsYT/9DAk1viuGTos91fh5A3Ibu7BlfiRAzdgUgOOT L83JzpAX7lBAanpM9p0wFp0JRERyiMoka3Xll5NIwSXwnQ6L23y40mVrH10HvGta3v /6ycCno88Y9KQ== X-Virus-Scanned: amavisd-new at efficios.com In-Reply-To: <20190402190253.GT26605@port70.net> X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.12_GA_3794 (ZimbraWebClient - FF65 (Linux)/8.8.12_GA_3794) Thread-Topic: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Thread-Index: Rg0mT9xqPX+gMKvVpOTwjeiNuFi6FA== Xref: news.gmane.org gmane.linux.lib.musl.general:14050 Archived-At: ----- On Apr 2, 2019, at 3:02 PM, Szabolcs Nagy nsz@port70.net wrote: > * Mathieu Desnoyers [2019-03-26 14:01:08 > -0400]: >> ----- On Mar 26, 2019, at 1:45 PM, Szabolcs Nagy nsz@port70.net wrote: >> > i agree that the current behaviour is not ideal, but >> > iterating over /sys/devices/system/cpu/cpu* may not >> > be correct either.. based on current linux api docs. >> > >> > i don't understand why is that number different from the >> > cpu set in /sys/devices/system/cpu/possible >> >> I suspect both iteration over /sys/devices/system/cpu/cpu* and >> content of /sys/devices/system/cpu/possible should provide the >> same result. However, looking at Linux >> Documentation/ABI/testing/sysfs-devices-system-cpu , >> it appears that /sys/devices/system/cpu/possible was introduced >> in December 2008, whereas /sys/devices/system/cpu/cpu#/ was there >> pre-git history. >> >> This could explain why glibc uses the iteration method. >> >> Thoughts ? > > as far as i can tell the cpu iteration method is valid, > and that directory list cannot change after boot (is this > guaranteed by the linux abi in the future?), so as long > as /sys is mounted we can get the number, but it's fairly > ugly.. does lttng have fallback code if sysconf returns -1? > if it does maybe musl should just do that (or somebody has > to write cancellation safe directory traversal code) Nope, the lttng-ust ring buffer won't be usable anyway. I *think* we need to improve the error handling for that scenario within our consumer daemon which is responsible for buffer allocation. I don't think we properly error out if the internal variable tracking the number of CPUs in the system stays at its unitialized value of 0. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com