From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13982 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: Sat, 16 Mar 2019 09:58:41 -0400 (EDT) Message-ID: <753776913.7980.1552744721723.JavaMail.zimbra@efficios.com> References: <20190315210202.GD6994@joraj-alpa> <20190316022534.GN26605@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="34989"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com, Michael Jeanson , Richard Purdie , Jonathan Rajotte To: Szabolcs Nagy Original-X-From: musl-return-13998-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 16 16:31:30 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 1h5BHU-0008yj-Lp for gllmg-musl@m.gmane.org; Sat, 16 Mar 2019 16:31:28 +0100 Original-Received: (qmail 4086 invoked by uid 550); 16 Mar 2019 15:31:26 -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 14179 invoked from network); 16 Mar 2019 13:58:54 -0000 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 07CF19EBCE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1552744722; bh=N6anOtYb8r6I27nwHR2Lo5XzfsziJjSujx469NGjBCs=; h=Date:From:To:Message-ID:MIME-Version; b=U5eI8zMSqyeqXVDgbkANrW2UrlrcSuevc88TOhdvI9ULE+KEkZAcapsStB4eIUF+3 MFQp3FQ5C4SHZHQwAtRYX7ejnl/cImo+imL0P+tcO8q8eSeCv1R0v/I4XqFNuiBFyE jnva7Kk0eEvztxRJP73V5+4iv/UKcJVIcn607WbBEmD1wGiYIiwCw9irG4g4oEcQ7m sGvHCUgwyMOCsEjluF99QKrHQcDVVegz9DnRsb0t+xzIjD1vSZKgjbBRKX8TYU8PuO J9Rjl0I0WXSb9YW6I6z6RP8iSnsXXG56W4Zhsbl2aE7innIvNIqTEWMSTP2WQv4eq1 iF5BAIRPE1tfw== X-Virus-Scanned: amavisd-new at efficios.com In-Reply-To: <20190316022534.GN26605@port70.net> X-Originating-IP: [167.114.142.138] X-Mailer: Zimbra 8.8.11_GA_3780 (ZimbraWebClient - FF65 (Linux)/8.8.11_GA_3780) Thread-Topic: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value Thread-Index: s1HaXGoRnfsXTkYztQpJhY7f+7cTWA== Xref: news.gmane.org gmane.linux.lib.musl.general:13982 Archived-At: ----- On Mar 15, 2019, at 10:25 PM, Szabolcs Nagy nsz@port70.net wrote: > * Jonathan Rajotte-Julien [2019-03-15 > 17:02:02 -0400]: >> We are currently in the process of making sure that lttng [1] (linux tracer) run >> smoothly on system using musl (Yocto, Alpine etc.). Most things work >> fine. Still, we currently have tests that are failing due to an issue regarding >> the reported number of configured processors on the system >> (__SC_NPROCESSORS_CONF). >> Note that users of LTTng are also affected by this if they chose to modify the >> sched affinity of their instrumented apps. This is relatively a big deal for us. [...] > i think we need to know why does a process care if musl returns > the wrong number? or what are the valid uses of such a number? > (there are heterogeous systems like arm big-little, numa systems > with many sockets, containers, virtualization,.. how deep may a > user process need to go down in this rabbit hole?) The use-case for LTTng-UST is as follows: it implements a ring buffer which is allocated (taking NUMA affinity into account) and owned by a centralized daemon (lttng-consumerd), passed to traced applications as file descriptors over unix sockets, and then memory-mapped into each application address space. This ring buffer is a per-cpu buffer for performance reasons. The way LTTng-UST handles cpu hotplug is to pre-allocate buffers for all possible CPUs, hand them over to applications, so those applications can always find an allocated buffer to write into for the current cpu reported by sched_getcpu(), even after a cpu hotplug. In comparison, the LTTng-modules Linux kernel tracer can do a much more clever use of memory resources, because it has access to cpu hotplug kernel modules APIs, which allows it to allocate buffers only for online CPUs. Unfortunately, there is no way to do this for user-space buffers that I'm aware of other than lazily allocating the resources on first use, and we cannot do this because allocation is performed by a centralized daemon (not by the application being traced and doing the actual "first use"). Moreover, as an overall design guide-line, we keep lazy allocation to a minimum in LTTng-UST, so tracing does not cause unexpected application latency. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com