Re: widening ticks
- Reply: Mark Johnston : "Re: widening ticks"
- Reply: Mark Johnston : "Re: widening ticks"
- In reply to: Mark Johnston : "widening ticks"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 08 Jan 2025 22:18:48 UTC
On Wed, Jan 08, 2025 at 04:31:16PM -0500, Mark Johnston wrote: > The global "ticks" variable counts hardclock ticks, it's widely used in > the kernel for low-precision timekeeping. The linuxkpi provides a very > similar variable, "jiffies", but there's an incompatibility: the former > is a signed int and the latter is an unsigned long. It's not > particularly easy to paper over this difference, which has been > responsible for some nasty bugs, and modifying drivers to store the > jiffies value in a signed int is error-prone and a maintenance burden > that the linuxkpi is supposed to avoid. > > It would be nice to provide a compatible implementation of jiffies. I > can see a few approaches: > - Define a 64-bit ticks variable, say ticks64, and make hardclock() > update both ticks and ticks64. Then #define jiffies ticks64 on 64-bit > platforms. This is the simplest to implement, but it adds extra work > to hardclock() and is somewhat ugly. > - Make ticks an int64_t or a long and convert our native code > accordingly. This is cleaner but requires a lot of auditing to avoid > introducing bugs, though perhaps some code could be left unmodified, > implicitly truncating the value to an int. For example I think > sched_pctcpu_update() is fine. I've gotten an amd64 kernel to compile > and boot with this change, but it's hard to be confident in it. This > approach also has the potential downside of bloating structures that > store a ticks value, and it can't be MFCed. > - Introduce a 64-bit ticks variable, ticks64, and > #define ticks ((int)ticks64). This requires renaming any struct > fields and local vars named "ticks", of which there's a decent number, > but that can be done fairly mechanically. > > Is there another solution which avoids these pitfalls? If not, should > we go ahead with one of these approaches? If so, which one? You cannot do this in C, but can in asm: .data .globl ticksl, ticks .type ticksl, @object .type ticks, @object ticksl: .quad .size ticksl, 8 ticks =ticksl /* for little-endian */ /* ticks =ticksl + 4 for big-endian */ .size ticks, 4 Then update only ticksl in the hardclock().