On Tue, Feb 18, 2014 at 12:20 PM, Thomas Gleixner <t...@linutronix.de> wrote: > On Mon, 17 Feb 2014, John Stultz wrote: > >> From: Stephen Boyd <sb...@codeaurora.org> >> >> The generic sched_clock registration function was previously >> done lockless, due to the fact that it was expected to be called >> only once. However, now there are systems that may register >> multiple sched_clock sources, for which the lack of locking has >> casued problems: >> >> If two sched_clock sources are registered we may end up in a >> situation where a call to sched_clock() may be accessing the >> epoch cycle count for the old counter and the cycle count for the >> new counter. This can lead to confusing results where >> sched_clock() values jump and then are reset to 0 (due to the way >> the registration function forces the epoch_ns to be 0). >> >> Fix this by reorganizing the registration function to hold the >> seqlock for as short a time as possible while we update the >> clock_data structure for a new counter. We also put any >> accumulated time into epoch_ns instead of resetting the time to >> 0 so that the clock doesn't reset after each successful >> registration. >> >> Cc: Peter Zijlstra <pet...@infradead.org> > > Peter ???
So this is the generic sched_clock work, which Peter really hasn't had much involvement with yet (mostly because its not yet generic enough to work with more then a few arches). But I included him in the CC since I think it would be good to have him following along. 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/
