From nobody Sat Feb 4 23:07:34 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P8Spy6f8Sz3kWt3; Sat, 4 Feb 2023 23:07:38 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4P8Spy3vysz3xY8; Sat, 4 Feb 2023 23:07:38 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; none Date: Sun, 05 Feb 2023 00:07:34 +0100 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Mateusz Guzik Cc: Mateusz Guzik , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: d9d5f2c042a5 - main - cpuset: add --count Message-ID: <20230204230734.U91zY%steffen@sdaoden.eu> In-Reply-To: References: <202302041751.314HpRrn042970@gitrepo.freebsd.org> <20230204203529.CusFt%steffen@sdaoden.eu> Mail-Followup-To: Mateusz Guzik , Mateusz Guzik , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org User-Agent: s-nail v14.9.24-403-gdc9ff6b368 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4P8Spy3vysz3xY8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mateusz Guzik wrote in : |On 2/4/23, Steffen Nurpmeso wrote: |> Mateusz Guzik wrote in |> <202302041751.314HpRrn042970@gitrepo.freebsd.org>: |>|The branch main has been updated by mjg: |>| |>|URL: https://cgit.FreeBSD.org/src/commit/?id=3Dd9d5f2c042a51a9f0dd69eb1= fc3\ |>|49efd81ffa483 |>| |>|commit d9d5f2c042a51a9f0dd69eb1fc349efd81ffa483 |>|Author: Mateusz Guzik |>|AuthorDate: 2023-02-04 17:47:41 +0000 |>|Commit: Mateusz Guzik |>|CommitDate: 2023-02-04 17:50:41 +0000 |>| |>| cpuset: add --count |>| |>| Can be used to count the number of hardware threads in the cpu set. |> ... |>| The intent is to replace calls to sysctl hw.ncpu and kern.smp.cpus \ |>| which |>| can be found in the tree, which are not adequate given existence of |>| cpusets. |> |> This is great (in respect to a #freebsd IRC from 2021-07-02)! |> Are there plans to address |> |> 19:26 < RhodiumToad> and in fact sysconf(_SC_NPROCESSORS_ONLN) is |> implemented as sysctl hw.ncpu |> |> or |> |> 19:25 < RhodiumToad> on fbsd 13 on a 4-cpu box, cpuset -l 0-1 getconf |> _NPROCESSORS_ONLN returns 4 rather than 2 |> | |So I just checked on Linux and get: |$ taskset --cpu-list 0 getconf _NPROCESSORS_ONLN |4 At least it does not count totally disabled SMT CPUs (here), but true, also cgroup'ized restricted ones show up "falsely" for 6.1. (This could be a "bug" in the C library though, as this checks /sys/devices/system/cpu/online (nproc(1) even fails in boxes without /sys/), /proc/stat, and only then (iirc now) uses sched_getaffinity. It documents get_nprocs(3) as "number of processors currently available in the system". POSIX standardized these[1] as _SC_NPROCESSORS_CONF + _SC_NPROCESSORS_ONLN for sysconf(3) as well as NPROCESSORS_CONF and NPROCESSORS_ONLN for getconf(1), saying ... The maximum number of execution units | _SC_NPROCESSORS_ONLN currently available to run threads=E2=80=A0 | .... =E2=80=A0 The nature of an execution unit and the precise conditions under which an execution unit is considered to be available, or can be made available, or how many threads it can execute in parallel, are implementation-defined. Which is not the same. Implementation-defined though. But i mean if it is easy to give correct results for an execution context (i would). [1] https://austingroupbugs.net/view.php?id=3D339 |iow the current behavior is probably the expected one. |> or even add a shallow usr.bin/nproc(1) that does only this |> operation, as in Linux? (Or ln(1) it and check out argv[0] to do |> so?) Having a "portable" thing would be great. | |I have no opinion on this one, looks a trivial addition, but someone |else will have to ack it (most notably whether to add it to cpuset as |you suggested above or create new utility altogether). | |That said, happy to take a look at a patch which adds a *new* |nproc utility. #!/bin/sh - if [ $# -ne 0 ]; then echo >&2 'Synopsis: nproc' exit 1 fi exec cpuset --count .Dd February 4, 2023 .Dt NPROC 1 .Os .Sh NAME .Nm nproc .Nd print the number of available processing units .Sh SYNOPSIS .Nm .Sh DESCRIPTION .Nm prints the number of processing units available to the current process, which may be less than the number of online processors. .Sh "SEE ALSO" .Xr cpuset 1 .Sh HISTORY Appeared in .Fx 14 . Ciao, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)