On Thu, Apr 2, 2015 at 11:34 AM, Peter Zijlstra <pet...@infradead.org> wrote: > On Thu, Apr 02, 2015 at 10:30:18AM -0700, John Stultz wrote: >> > Should we make a further note that the tk_fast things rely on this >> > slack since they're not strongly serialized against this? That is, they >> > can end up using an older cycle_last value and therefore end up with a >> > larger delta than other code. >> >> Though, even with the tk_fast bits, we expect the update to happen >> regularly, its just that for the benefit of lock-free access we are ok >> with the possible slight inconsistencies (in the mono clock) that >> could happen if we use a slightly stale value mid-update. So I don't >> think the tk_fast bits are actually relying on the slack any more then >> the normal timekeeping code relies on the slack to handle slight >> delays in processing the updates. If we deal with time deltas large >> enough to cause overflows, or time intervals larger then the hardware >> can represent, we're sunk in either case. This 50% margin just makes >> it easier to catch unexpected delays or issues. > > Right, so you're saying that even though the fast bits will see slightly > larger deltas than the normal code, they should still not get anywhere > near the 50% because we update much more frequently?
Well, they may get to 50% or slightly over (since 50% is the max nohz idle length), but that's likely rare, and we shouldn't get anywhere close to real failure edges (100% be it the mult-overflow or hardware mask limit). thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
