From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-18.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 571ACC433EF for ; Wed, 15 Sep 2021 17:59:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 40B3C61247 for ; Wed, 15 Sep 2021 17:59:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231869AbhIOSAu (ORCPT ); Wed, 15 Sep 2021 14:00:50 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:51395 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231559AbhIOSAi (ORCPT ); Wed, 15 Sep 2021 14:00:38 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7F1E25C019D; Wed, 15 Sep 2021 13:59:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Wed, 15 Sep 2021 13:59:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ilammy.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=fm2; bh=64zNka2i99bu6 M6rOrxFBM4wYz2D6lob8RpvLi07K+8=; b=lHZsmmPUVc4LqK0ph5U7iNOOlJxYa UfzCVpqZa3WXc5+NRC7C1QTICXhCP2lc8qJNMisEx741tK3y7bf3hH0au9l+yePN V/yILd2KScKamQlzxQ16WjAP/862jhoVhu0y/wLr1mB7bG9pFRKMPWmS0X/iSdRw Dae7878plfo1ZboVM7CvrYF66uFVu18+Kr20RR1ZRYXr0lntV/d7xFSXkw+uMZ7P klBFcvdXSwk944Oa7mmfk58QC8aF2UwtpcxNM84em2zTN0AGZP4mcohUu4s4EiNQ dJkYbXht5yzUadLWLD8I/rDDv03N42fI/ZvWkVee/FA1QPH9Vi/+HfwBg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :in-reply-to:message-id:mime-version:references:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=64zNka2i99bu6M6rOrxFBM4wYz2D6lob8RpvLi07K+8=; b=rnKOm2Si yqM1UY2e1nROhrp6opivon9mMKgScm+k2suSPcsNvT29Wf5ry7TQNv9V68anZLmw rKhkJwh8TZS4qnYP9ZnJ+8vLGcTX9ynJAVweu/bHG9e5qmTB/F0yUze9shRyGRj1 wZwRSbuEuOX/CMRdCkGtvyQX2y5CREqfhUuNdWpWcOsz2nDM00bDXd6cA823FsKq EAhHrbRVt7Bwvk9QHvg4GvrNtAk2CMQvtcOrgTkaLLUUNNQIS5FH44N8qtlRHVO0 n4kXrQZW6t2PdrlB/Hw7IXpVd4M72gvT7lET4LXIyw0TrzneQadoJLXSHqEoFqNf 23i35U7W+BTwKg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehuddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkofgjfhgggfestdekredtredttdenucfhrhhomheptehlvgig vghiucfnohiiohhvshhkhicuoehmvgesihhlrghmmhihrdhnvghtqeenucggtffrrghtth gvrhhnpeetueejheekjeeuveeihefgueehleelgefgheefffefkeejudeujeejuefgteeu keenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmvg esihhlrghmmhihrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Sep 2021 13:59:16 -0400 (EDT) From: Alexei Lozovsky To: Thomas Gleixner Cc: Alexey Dobriyan , Christoph Lameter , LKML , linux-fsdevel@vger.kernel.org Subject: [PATCH v2 12/12] docs: proc.rst: stat: Note the interrupt counter wrap-around Date: Thu, 16 Sep 2021 02:58:48 +0900 Message-Id: <20210915175848.162260-13-me@ilammy.net> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210915175848.162260-1-me@ilammy.net> References: <20210911034808.24252-1-me@ilammy.net> <20210915175848.162260-1-me@ilammy.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Let's make wrap-around documented behavior so that userspace has no excuses for not handling it properly if they want accurate values. On 32-bit platforms "intr" and "softirq" counters can and will wrap-around, given enough time since boot. This can be days or hours, depending on the load. On 64-bit platforms these counters use 64-bit values and these are very unlikely to oveflow before the heat death of the universe, but it's still technically possible. Many other counters can wrap-arond too but I'm not going to enumerate all of them here. The interrupt counters are most likely to overflow. Signed-off-by: Alexei Lozovsky --- Documentation/filesystems/proc.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 042c418f4090..a33af0074838 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -1513,6 +1513,14 @@ interrupts serviced including unnumbered architecture specific interrupts; each subsequent column is the total for that particular numbered interrupt. Unnumbered interrupts are not shown, only summed into the total. +.. note:: + + On 32-bit platforms interrupt counters are 32-bit, including the total + count of all interrupts. Depending on the system load, these values will + sooner or later wrap around. If you want accurate accounting of the rate + and *actual* number of interrupts serviced, you should monitor the value + closely and handle wrap-arounds. + The "ctxt" line gives the total number of context switches across all CPUs. The "btime" line gives the time at which the system booted, in seconds since -- 2.25.1