jiffies_64

[Chris Wedgwood <cw@f00f.org>]

On Sat, Jun 26, 2004 at 03:48:34PM -0700, Linus Torvalds wrote:

> So please tell me where the jiffies64 thing was suddenly correct as
> a "volatile", and I can almost guarantee you that you were WRONG to
> mark it volatile.

In this case it's a platform where moving jiffies around is very
painful so I have a patch to make jiffies per-CPU using the local APIC
timer (jiffies becomes a macro to get_local_jiffies() with all the
horrors that come with that).

Because this drifts we use the PIT as a referrence and resynchronize
every few seconds against jiffies_64.

A few places can't actually use get_local_jiffies() early on like the
bogomips calibration code (because the local APIC timer isn't working
yet) so I've got some hacks in there where they use jiffies_64.

> But you're right, on a 64-bit architecture, jiffies_64 falls back to
> the "jiffies" case, and there it would be acceptable to make it
> volatile.

Actually, I don't like the way we use xtime_lock at all for jiffies_64
now.  Things are unclear and fragile in places.  In my tree I have
jiffies_64 protected by a spinlock instead of the seqlock thing (as it
still needs to be locked even though it's incremented only from one
CPU in irq context) and was looking at using cmpxchg8 on platforms
what can to remove the need to lock jiffies_64 completely.

I've wondered if we can't do the same thing for xtime as well,
however I need to make per-CPU xtime so I'll revisit that when I get a
chance.

> See? The volatile is (again) wrong on the data structure (jiffies_64), and
> you should have added it to the code (get_jiffies_64).

get_jiffies_64() in my case reads the per-CPU value and like I said a
few places don't like that.


  --cw