From: Thomas Gleixner <tglx@linutronix.de>
To: Alexei Lozovsky <me@ilammy.net>, Alexey Dobriyan <adobriyan@gmail.com>
Cc: Christoph Lameter <cl@linux.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/7] proc/stat: Maintain monotonicity of "intr" and "softirq"
Date: Tue, 14 Sep 2021 16:11:21 +0200 [thread overview]
Message-ID: <87y27zb62e.ffs@tglx> (raw)
In-Reply-To: <44F84890-521F-4BCA-9F48-B49D2C8A9E32@ilammy.net>
On Sun, Sep 12 2021 at 21:37, Alexei Lozovsky wrote:
> On Sun, Sep 12, 2021, at 18:30, Alexey Dobriyan wrote:
>> How about making everything "unsigned long" or even "u64" like NIC
>> drivers do?
>
> I see some possible hurdles ahead:
>
> - Not all architectures have atomic operations for 64-bit values
This is not about atomics.
> All those "unsigned int" counters are incremented with __this_cpu_inc()
> which tries to use atomics if possible. Though, I'm not quite sure
It does not use atomics. It's a CPU local increment.
> how this works for read side which does not seem to use atomic reads
> at all. I guess, just by the virtue of properly aligned 32-bit reads
> being atomic everywhere? If that's so, I think widening counters to
> 64 bits will come with an asterisk.
The stats are accumulated racy, i.e. the interrupt might be handled and
one of the per cpu counters or irq_desc->tot_count might be incremented
concurrently.
On 32bit systems a 32bit load (as long as the compiler does not emit
load tearing) is always consistent even when there is a concurrent
increment going on. It either gets the old or the new value.
A 64bit read on a 32bit system is always two loads which means that a
concurrent increment will make it possible to observe a half updated
value. And no, you can't play reread tricks here without adding barriers
on weakly ordered architectures.
> - We'll need to update all counters to be 64-bit.
>
> Like, *everyone*. Every field that gets summed up needs to be 64-bit
> (or else wrap-arounds will be incorrect). Basically every counter in
> every irq_cpustat_t will need to become twice as wide. If that's
> a fine price to pay for accurate, full-width counters...
The storage size should not be a problem.
> So right now I don't see why it shouldn't be doable in theory.
So much for the theory :)
Thanks,
tglx
next prev parent reply other threads:[~2021-09-14 14:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 8:53 /proc/stat interrupt counter wrap-around Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 0/7] proc/stat: Maintain monotonicity of "intr" and "softirq" Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 1/7] genirq: Use unsigned int for irqs_sum Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 2/7] powerpc/irq: arch_irq_stat_cpu() returns unsigned int Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 3/7] x86/irq: " Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 4/7] x86/irq: arch_irq_stat() " Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 5/7] proc/stat: Use unsigned int for "intr" sum Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 6/7] proc/stat: Use unsigned int for "softirq" sum Alexei Lozovsky
2021-09-11 3:48 ` [PATCH 7/7] docs: proc.rst: stat: Note the interrupt counter wrap-around Alexei Lozovsky
2021-09-11 3:59 ` Randy Dunlap
2021-09-12 9:30 ` [PATCH 0/7] proc/stat: Maintain monotonicity of "intr" and "softirq" Alexey Dobriyan
2021-09-12 12:37 ` Alexei Lozovsky
2021-09-14 14:11 ` Thomas Gleixner [this message]
2021-09-15 4:24 ` Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 00/12] " Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 01/12] genirq: Use READ_ONCE for IRQ counter reads Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 02/12] genirq: Use unsigned long for IRQ counters Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 03/12] powerpc/irq: Use READ_ONCE for IRQ counter reads Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 04/12] powerpc/irq: Use unsigned long for IRQ counters Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 05/12] powerpc/irq: Use unsigned long for IRQ counter sum Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 06/12] x86/irq: Use READ_ONCE for IRQ counter reads Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 07/12] x86/irq: Use unsigned long for IRQ counters Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 08/12] x86/irq: Use unsigned long for IRQ counters more Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 09/12] x86/irq: Use unsigned long for IRQ counter sum Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 10/12] proc/stat: Use unsigned long for "intr" sum Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 11/12] proc/stat: Use unsigned long for "softirq" sum Alexei Lozovsky
2021-09-15 17:58 ` [PATCH v2 12/12] docs: proc.rst: stat: Note the interrupt counter wrap-around Alexei Lozovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y27zb62e.ffs@tglx \
--to=tglx@linutronix.de \
--cc=adobriyan@gmail.com \
--cc=cl@linux.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=me@ilammy.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.