Hi... :) On Fri, Nov 19, 2010 at 02:56, Adrian Cornish <adrianc@xxxxxxx> wrote: > Hi all, > > The following code will exit (in a few seconds usually) - which I would > expect it not too. Since gettimeofday is called before time(). Obviously > this is compiled without optimization. IMO, if both are really fetching time from clock source like RTC, then it might take long..however, the reality in kernel code, AFAIK, it's not like that. It's more like jiffies plus ...I could say, "fuzzy factor". Jiffies itself, in turn, is updated only every 1/HZ seconds. This could be less when we use no_hz... > They both use the same timer (xtime) but gettimeofday() calls > getnstimeofday() which calls timespec_add_ns(), which can modify the > seconds portion of timespec struct. I dont understand why > getnstimeofday() uses a loop and then adds on nanoseconds to the result? I can only provide some rough guess: as I said above, it adds some "fuzz factor". And IMO, this is not a random number. I dare to guess it's calculated time to time as a representation of clock difference (or shall I say, clock drift?) between one updated every 1/HZ and the real clock in RTC. AFAIK fetching time directly RTC is an expensive operation (meaning: needs many cpu cycles), thus it would be wiser to just use updated jiffies. As to why it needs to do it repeatedly? That I don't really know. Likely, it is done more than once since the time value we read might be a value that is updated "in flight". Thus, to be sure, we read multiple times. AFAIK seq lock is unblocking lock, thus to avoid contention over several reader that might need time read too. Hopefully I am offering logical explanation...all above are purely my interpretation based directly from code reading. -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
