Messages in this thread |  | | Date | Wed, 31 Oct 2001 14:07:43 -0700 | | From | Andreas Dilger <> | | Subject | Re: [Patch] Re: Nasty suprise with uptime |
| |
On Oct 31, 2001 21:47 +0100, Tim Schmielau wrote: > OK, I introduced get_jiffies64, corrected my 64 bit mistake and > subtract INITIAL_JIFFIES to obtain uptime, while leaving it at at pre-wrap > value for error-chasing. > Still this patch introduces jiffies_high on 64 bit platforms which will be > useless until the year 571234830.
It probably won't be accepted until the whole thing disappears for 64-bit systems.
> btw.: can someone please explain to me why do_timer uses > (*(unsigned long *)&jiffies)++; > instead of just doing jiffies++ ?
Can't say for sure, but it may be a compiler issue, maybe historical.
> */ > #if HZ!=100 > len = sprintf(page,"%lu.%02lu %lu.%02lu\n", > - uptime / HZ, > - (((uptime % HZ) * 100) / HZ) % 100, > + (unsigned long) uptime, > + ((remainder * 100) / HZ) % 100, > idle / HZ, > (((idle % HZ) * 100) / HZ) % 100);
Given that uptime is now 64-bits, do we need this mathematical hoop jumping? Also, won't the remainder already be modulus HZ in this case?
> void do_timer(struct pt_regs *regs) > { > - (*(unsigned long *)&jiffies)++; > + /* we assume that two calls to do_timer can never overlap > + * since they are one jiffie apart in time */ > + if (jiffies != (unsigned long)(-1)) { > + jiffies++; > + } else { > + /* We still need to care about the race with readers of > + * jiffies_hi. Readers have to discard the values if > + * jiffies_hi != jiffies_hi_shadow when read with > + * proper barriers in between. */ > + jiffies_hi++; > + barrier(); > + jiffies++; > + barrier(); > + jiffies_hi_shadow = jiffies_hi; > + barrier(); > + }
I think this is the part of the patch that people object to. See my other posting of how to handle 64-bit jiffies with only an impact to users of the 64-bit value.
Cheers, Andreas -- Andreas Dilger http://sourceforge.net/projects/ext2resize/ http://www-mddsp.enel.ucalgary.ca/People/adilger/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |