DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 48JDEaXq2591072 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=QjbUlFAu X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 46DF8385700F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1726751673; bh=KyQcpDFW6AARoBsWOUFQF1IwjHseUV+5PTZjFTLW1UE=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=QjbUlFAujxUuX/iFrtrjZ60X3U27IxvCQbwnBj12AjcLveUK9BK4R/5xjHqTip4/0 DlOeX5d6idz74Wj2gI2CO5uOGCWdI0E/X4FqeNyCzEstaTup0XzPtGgaFmZ0xmjRz0 6Wpr+2dp88VtRhcHQ060r7+mFNN/fY6Cr6yyXFcE= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1589B3858CD9 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1589B3858CD9 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726751651; cv=none; b=teGL4Gxp3u39pU4cPQ5fJNdUVv6L2D/0ZUJOGMsXEcxjTgkSSYjoR5GnWdIXV1A/Tmptz+yfnsCX1zsy1cYbVOgwOOl2VYnXG+5JpgHbXCQ7PJWPGNNymeaPM5HN7wCh2Vf3KOPzJXB6DF295l+4IQdPmP6RB/JtINQZPIcAGjA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726751651; c=relaxed/simple; bh=M9kKE80VT7KmSfkBm/N/8n94Pl9tpEqr62pdfHuIIg4=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=gVNpcKzDTQbKUlgPWAfAEyEeNeNfBWNu/tB13INjSoaxiSSvQf9j6DaHBBzhLttkVWmtBnBtP2yFWiMxlQE0uzcDlHn8X37JlNYB2DoUW6M7JobwiVgYjFv7YyCzORxVWHsRsIJrv2WW+SGZBrzzAyDix5THVcYX24Z4Pjn65sg= ARC-Authentication-Results: i=1; server2.sourceware.org X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726751647; x=1727356447; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kmqUgfMvPb33j5aUv9+W7LmnPaOPqYvoZukvqkFW960=; b=pe3t+5muRr9zyf60Ap2v30ye8WURukyvjK/H9kwGpyghLVoObcS2caiUaxH67BS841 hOAwWyXkFhTGp6/pWC+TSvtUxq1vvlLX7iJ6z0/cSW0IYaV+Lvyxn2YuRzUmmViKKDpy tJ7rKUNKFPnrJTT+gd8coRZ+eapS39022lC6KiOAcJ/Ai9/pMow5ruwoyELvp2yUurwU S0jOB0pzSdFBSPMzmoh1mC87HGQP2Gmj1UHRsKwpoZgxKEEXU2voYHdKG96s/gJ3F7Ym 9rzX+wyClVOK+iAt+S71nvOueCKPMnJxdY6PNoyYSdAo356v10rjvhcTwXAs3LpxFG16 EiTw== X-Gm-Message-State: AOJu0YxKsFd85xQrxBgiriiUdMSdNljGzW4sQXP3o9BOJl5KN7xqhLI6 zIRNq0hlS1rzlcMFICz5ucWFUFj+0AX2KpLmp88t3d7cL0mG9LXw2hW5qnpQv8uQODQAdZKRv7G B1p9yO62ajzqqnoco6AMyXw1R6rRotb/Qls4tEOw/ X-Google-Smtp-Source: AGHT+IGKL3qXTNRQG7RS7jM4tGPfu0+rQwPfzqpN3b1do6Dval7kKC8gp5zba55N6FAJ0/SVH6AkC2HC51umw0b5eTw= X-Received: by 2002:aa7:c483:0:b0:5c2:4bd1:30c3 with SMTP id 4fb4d7f45d1cf-5c413e4d024mr20824391a12.27.1726751647160; Thu, 19 Sep 2024 06:14:07 -0700 (PDT) MIME-Version: 1.0 References: <2225cf8a-cb8a-6437-177d-9a83f7dec53c AT cs DOT umass DOT edu> In-Reply-To: <2225cf8a-cb8a-6437-177d-9a83f7dec53c@cs.umass.edu> Date: Thu, 19 Sep 2024 15:13:30 +0200 Message-ID: Subject: Re: BUG: /usr/bin/uptime always reports 0/0/0 average To: cygwin AT cygwin DOT com X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 List-Id: General Cygwin discussions and problem reports List-Archive: List-Post: List-Help: List-Subscribe: , From: Cedric Blancher via Cygwin Reply-To: Cedric Blancher Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Cygwin" On Tue, 27 Aug 2024 at 18:30, Eliot Moss via Cygwin wrote: > > On 8/27/2024 11:31 AM, Jon Turney via Cygwin wrote: > > On 27/08/2024 09:21, Mark Liam Brown via Cygwin wrote: > >> Greetings! > >> > >> /usr/bin/uptime always reports 0/0/0 average cpu load: > >> $ uptime > >> 10:09:01 up 15:59, 0 user, load average: 0.00, 0.00, 0.00 > >> > >> is this a known bug? > > > > Kind of. > > > > Due to windows API limitations, the current implementation has the short-coming that a process's first call to > > getloadavg() does not update the globally-maintained loadavg data. > > > > (Because the Windows API cannot provide instantaneous cpu load, only over the period between two calls) > > > > (So e.g. if you run something like top in another terminal, you'll suddenly see uptime return more sensible values) > > > > See the discussion [1] for more context, and discussion of various approaches to fixing this, which petered out without > > a patch to [2]... > > > > [1] https://cygwin.com/pipermail/cygwin-developers/2022-May/012569.html > > [2] https://cygwin.com/cgit/newlib-cygwin/tree/winsup/cygwin/loadavg.cc > > Thank you for the explanation, Mark! > > I see that /proc/loadavg appears to get updated. If one wants the information, > is that a more reliable source than calling uptime for load averages? I get this on a stressed system with HUNDREDS of running processes: $ cat /proc/loadavg 0.00 0.00 0.00 1/21 The problem is that this breaks parallel builds (e.g. GNU make, dmake, ...), which all rely on getloadavg() to cap/limit starting new processes until the load goes below a certain threshold. Returning just 0.0/0.0/0.0 is basically the IT equivalent for the nuclear option: Launch more and more processes, check getloadavg(), which returns "system is idle", which causes more and more processes being started, until the machine grinds to a halt for interactive users. That is... pretty bad. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple