From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-10.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31416 invoked from network); 5 May 2021 17:21:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 May 2021 17:21:30 -0000 Received: (qmail 30453 invoked by uid 550); 5 May 2021 17:21:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 30433 invoked from network); 5 May 2021 17:21:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3LlflPCfaGTlsQ2r8NRyd2sghXSvA5l560brstzusw4=; b=FKg0T+2DcpJhQW7Ib2F3l3Hf1TgDvYOtIR+myn+RXNLVeSBjDF2riKoeXwvFaD4gDe BFrIwWSyii0dodR9SXrjz2kgljUBJwWaOSqsFA3mWWcf9m7uchfF13ALRitjpK7HNyWm +9NV+ecLVeFEspXLCYt0NNBv374VxnfE19ymG/MUwFhAMmBuPACR15pBbv1Dfo13BYNN /3makVYZHAZCjHhqEuJ9enZKiYmpps9pJdcqEcth9GOkc2JkqjRKZw6Tp1HicUiGx+FV YuYzA6z0AXMbLnA/hOeGj3ywCAL3s08pKsw/y8k97PKUr8AAnnpKUjqGcUYCvmBDOwpr Gs8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3LlflPCfaGTlsQ2r8NRyd2sghXSvA5l560brstzusw4=; b=poSzpghJoitnLp5/OK1vo16mux0lqes4QIBNnxVrPJzhMCPHSIfvE8M5iNJS9Rkpo0 qZ0OT9dX9aA3v+dQxJGyBZCzu2B3id5WKyxHUSm8zMNu6fAgB0iAQIgY+gRwtMMVskD2 BaQ6NK6Z5JfMxmBgplug5a10FUQ51iO/ZJVPFP7jNWRUZIbYIow8v/pQLRdq2xC+1xFO G2pTukqgj3mXvbGxcTUSzH/DLkBOr6bJOHSBI/A8HRx8crta2vSDMXEvYNlYfP1OZ/vN jqLdK5En8y0lE5fyBRxWTt8a0XdaYnLm/fmDQXz3WuNB4yoeahozvflaaD7hJN5L6Tap IXmg== X-Gm-Message-State: AOAM532hoQCjiGey8pD8jME9f7ixWRnbFsWEcdtWmHDdi76IWLMA59xL 2np4vbA8y26E4gvblwq34CTAGrlAx1S9TDAXQr5cjPJWYUxrxg== X-Google-Smtp-Source: ABdhPJzcbCWV8pgmpglaj8qJOmsK0OYnuoTI7lOUIOwxx8k2YQ2WEFX/VyaSkRvpkAPNeT410TqkgzwTYyzjwpOsX2M= X-Received: by 2002:a05:651c:a04:: with SMTP id k4mr23064163ljq.427.1620235275419; Wed, 05 May 2021 10:21:15 -0700 (PDT) MIME-Version: 1.0 References: <20210505130615.6222-1-vincent.donnefort@arm.com> In-Reply-To: From: James Y Knight Date: Wed, 5 May 2021 13:20:47 -0400 Message-ID: To: musl@lists.openwall.com Cc: Vincent Donnefort Content-Type: multipart/alternative; boundary="0000000000000b9d4d05c1986c7d" Subject: Re: [musl] [PATCH] sysconf: add _SC_NPROCESSORS_CONF support --0000000000000b9d4d05c1986c7d Content-Type: text/plain; charset="UTF-8" On Wed, May 5, 2021 at 10:05 AM Alexander Monakov wrote: > > > On Wed, 5 May 2021, Vincent Donnefort wrote: > > > Currently, _SC_NPROCESSORS_CONF is always equal to _SC_NPROCESSORS_ONLN. > > However, it is expected from the first one to give the total number of > CPUs > > in the system, while the later must return only the number of CPUs which > > are currently online. This distinction is important for a software such > as > > trace-cmd. Trace-cmd is a front-end for the kernel tracing tool ftrace. > > When recording traces, trace-cmd needs to get the total number of CPUs > > available in the system (_SC_NPROCESSORS_CONF) and not only the online > ones > > otherwise if a CPU goes offline some data might be missing. > BTW, it looks like what trace-cmd actually needs is the "largest cpu id-number that could exist this boot" (as used by sched_getaffinity, pthread_setaffinity_np, etc.) rather than "total number of CPUs which could exist this boot". Now, as far as I can tell _in practice_ the kernel always allocates "possible" cpu ids contiguously (so /sys/devices/system/cpu/possible will always contain e.g. "0-3", rather than something like "0,1,46,47"), but the data structures don't appear to require that. It's stored and reported as a bitmask. If Linux intends to guarantee that the "possible" bitset is (and will always) remain contiguous from 0, then the "largest" and "count" numbers are effectively equivalent, but otherwise they are not. > Hence, add a specific method to get _SC_NPROCESSORS_CONF, based on the > > sysfs CPU entries /sys/devices/system/cpu/cpu[0-9] > > Why do the opendir instead of reading from > /sys/devices/system/cpu/possible? > The online/offline/possible CPU masks are documented in > linux/Documentation/ABI/testing/sysfs-devices-system-cpu and > linux/Documentation/cputopology.txt The /sys/devices/system/cpu/cpuNN directories are created for every cpu in the "possible" bitmask, so those should be equivalent. I expect the reason glibc uses readdir is simply because "possible" was only introduced in Linux 2.6.26 in 2008. --0000000000000b9d4d05c1986c7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 5, 2021 at 10:05 AM Alex= ander Monakov <amonakov@ispras.ru<= /a>> wrote:


On Wed, 5 May 2021, Vincent Donnefort wrote:

> Currently, _SC_NPROCESSORS_CONF is always equal to _SC_NPROCESSORS_ONL= N.
> However, it is expected from the first one to give the total number of= CPUs
> in the system, while the later must return only the number of CPUs whi= ch
> are currently online. This distinction is important for a software suc= h as
> trace-cmd. Trace-cmd is a front-end for the kernel tracing tool ftrace= .
> When recording traces, trace-cmd needs to get the total number of CPUs=
> available in the system (_SC_NPROCESSORS_CONF) and not only the online= ones
> otherwise if a CPU goes offline some data might be missing.

BTW, it looks like what trace-cmd actually needs = is the "largest cpu id-number that could exist this boot" (as use= d by sched_getaffinity, pthread_setaffinity_np, etc.) rather than "tot= al number of CPUs which could exist this boot".

Now, as far as I can tell _in practice_ the kernel always allocates &quo= t;possible" cpu ids contiguously (so=C2=A0/sys/devices/system/cpu/poss= ible will=C2=A0always contain e.g. "0-3", rather than something l= ike "0,1,46,47"), but the data structures don't appear to req= uire that. It's stored and reported as a bitmask. If Linux intends to g= uarantee that the "possible" bitset is (and will always) remain c= ontiguous from 0, then the=C2=A0"largest" and "count" n= umbers are effectively equivalent, but otherwise they are not.
=C2=A0= > Hence, add a specific method to get _SC_NPROCESSORS_CONF, based on the=
> sysfs CPU entries /sys/devices/system/cpu/cpu[0-9]

Why do the opendir instead of reading from /sys/devices/system/cpu/possible= ?
The online/offline/possible CPU masks are documented in
linux/Documentation/ABI/testing/sysfs-devices-system-cpu and
linux/Documentation/cputopology.txt

--0000000000000b9d4d05c1986c7d--