From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vmicros1.altlinux.org (vmicros1.altlinux.org [194.107.17.57]) by sourceware.org (Postfix) with ESMTP id 2B19D3858D28 for ; Tue, 8 Feb 2022 22:40:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B19D3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=altlinux.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=altlinux.org Received: from mua.local.altlinux.org (mua.local.altlinux.org [192.168.1.14]) by vmicros1.altlinux.org (Postfix) with ESMTP id 4814A72C907; Wed, 9 Feb 2022 01:40:02 +0300 (MSK) Received: by mua.local.altlinux.org (Postfix, from userid 508) id 340BD7CD5E6; Wed, 9 Feb 2022 01:40:02 +0300 (MSK) Date: Wed, 9 Feb 2022 01:40:02 +0300 From: "Dmitry V. Levin" To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v2] linux: fix accuracy of get_nprocs and get_nprocs_conf [BZ #28865] Message-ID: <20220208224002.GA21338@altlinux.org> References: <20220205212402.GA5233@altlinux.org> <20220207135736.GA31310@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2022 22:40:05 -0000 On Tue, Feb 08, 2022 at 04:34:42PM -0300, Adhemerval Zanella wrote: > On 07/02/2022 10:57, Dmitry V. Levin wrote: > > get_nprocs() and get_nprocs_conf() use various methods to obtain an > > accurate number of processors. Re-introduce __get_nprocs_sched() as > > a source of information, and fix the order in which these methods are > > used to return the most accurate information. The primary source of > > information used in both functions remains unchanged. > > > > This also changes __get_nprocs_sched() error return value from 2 to 0, > > but all its users are already prepared to handle that. > > > > Old behavior: > > get_nprocs: > > /sys/devices/system/cpu/online -> /proc/stat -> 2 > > get_nprocs_conf: > > /sys/devices/system/cpu/ -> /proc/stat -> 2 > > > > New behavior: > > get_nprocs: > > /sys/devices/system/cpu/online -> /proc/stat -> sched_getaffinity -> 2 > > get_nprocs_conf: > > /sys/devices/system/cpu/ -> /proc/stat -> sched_getaffinity -> 2 > > > > Fixes: 342298278e ("linux: Revert the use of sched_getaffinity on get_nproc") > > Closes: BZ #28865 > > I am still not fully sure if sched_getaffinity is a correct fallback to an > API that should return a system overview, the issue that lead > sched_getaffinity removal was that it is subject to per-process filtering > (either by seccomp, cgroup, etc.) and it might trigger some wrong behavior > in some programs (such as monitoring tools and jvms). > > However if the environment does not provide a way to actually obtain such > information I guess sched_getaffinity should not make things worse (it does > not make sense to assume multiprocessor if the process is not allowed more > than one CPU, and monitoring tools should not work if sysfs/procfs are > not present). > > LGTM with some nits below. I think you might use brackets instead of > square bracket in title (to trigger the bugzilla scripts). I don't think it's the kind of brackets that trigger bugzilla scripts. > Reviewed-by: Adhemerval Zanella Corrected nits and pushed, thanks. -- ldv