mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Szabolcs Nagy <nsz@port70.net>
Cc: musl@lists.openwall.com, Michael Jeanson <mjeanson@efficios.com>,
	 Richard Purdie <richard.purdie@linuxfoundation.org>,
	 Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Subject: Re: sysconf(_SC_NPROCESSORS_CONF) returns the wrong value
Date: Sat, 16 Mar 2019 09:58:41 -0400 (EDT)	[thread overview]
Message-ID: <753776913.7980.1552744721723.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190316022534.GN26605@port70.net>

----- On Mar 15, 2019, at 10:25 PM, Szabolcs Nagy nsz@port70.net wrote:

> * Jonathan Rajotte-Julien <jonathan.rajotte-julien@efficios.com> [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


  reply	other threads:[~2019-03-16 13:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 21:02 Jonathan Rajotte-Julien
2019-03-16  2:25 ` Szabolcs Nagy
2019-03-16 13:58   ` Mathieu Desnoyers [this message]
2019-03-16 14:28   ` Jonathan Rajotte-Julien
2019-03-19 19:11   ` Florian Weimer
2019-03-26 16:23   ` Jonathan Rajotte-Julien
2019-03-26 17:45     ` Szabolcs Nagy
2019-03-26 18:01       ` Mathieu Desnoyers
2019-04-02 19:02         ` Szabolcs Nagy
2019-04-02 22:38           ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=753776913.7980.1552744721723.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=jonathan.rajotte-julien@efficios.com \
    --cc=mjeanson@efficios.com \
    --cc=musl@lists.openwall.com \
    --cc=nsz@port70.net \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).