On Tue, Apr 4, 2023 at 7:27 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
>
> Sometimes you want to add debugfs entries for atomic counters which
> can be pretty large using atomic64_t. Add support for these.
So I realize why you use atomic64, but I really suspect you'd be
better off with just the regular "atomic_long".
This is not some debug stat that we care deeply about on 32-bit, and
"atomic64" is often really really nasty on 32-bit architectures.
For example, on x86, instead of being a single instruction, it ends up
being a cmpxchg loop. In fact, even a single atomic read is a cmpxchg
(admittedly without the need for looping).
And yeah, I realize that we don't have a "atomic_long" debugfs
interface either. But I think we could just use atomic_long for the
module code (avoiding all the horrors of 64-bit atomics on 32-bit
architectures), and then using just 'var->counter' for the value. It's
not like the debugfs stuff actually does any truly atomic updates.
So something like
debugfs_create_ulong(... &val->counter ..);
instead of
debugfs_create_atomic64(... &val ..);
Hmm?
I dunno. I just think this is not something that may be worth
introducing a new thing for, when it is *so* painful on 32-bit, and
doesn't seem worth it.
Linus
