On Thu, Apr 02, 2015 at 11:41:15AM -0700, John Stultz wrote: > 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).
Right, so the fast thing rely on there being slack. That was my point rather. I know they'll not get to the end of slack. -- 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/
