Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-03 Thread Ingo Molnar
* John Stultz wrote: > On Thu, Apr 2, 2015 at 12:51 AM, Ingo Molnar wrote: > > > > * Peter Zijlstra wrote: > > > >> On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: > >> > Ingo suggested that the timekeeping debugging variables > >> > recently added should not be global, and

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-03 Thread Ingo Molnar
* John Stultz john.stu...@linaro.org wrote: On Thu, Apr 2, 2015 at 12:51 AM, Ingo Molnar mi...@kernel.org wrote: * Peter Zijlstra pet...@infradead.org wrote: On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: Ingo suggested that the timekeeping debugging variables

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread John Stultz
On Thu, Apr 2, 2015 at 12:51 AM, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > >> On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: >> > Ingo suggested that the timekeeping debugging variables >> > recently added should not be global, and should be tied >> > to the timekeeper's

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Thu, Apr 02, 2015 at 10:36:47AM +0200, Peter Zijlstra wrote: > Sure, struct timekeeper would work, the debug code already references > the global tk_core to access that. While looking at that, the comment near tk_core says: /* * The most important data for readout fits into a single 64 byte

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Thu, Apr 02, 2015 at 09:51:51AM +0200, Ingo Molnar wrote: > > * Peter Zijlstra wrote: > > > On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: > > > Ingo suggested that the timekeeping debugging variables > > > recently added should not be global, and should be tied > > > to the

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Ingo Molnar
* Peter Zijlstra wrote: > On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: > > Ingo suggested that the timekeeping debugging variables > > recently added should not be global, and should be tied > > to the timekeeper's read_base. > > But why? its the same hardware clock for both

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: > Ingo suggested that the timekeeping debugging variables > recently added should not be global, and should be tied > to the timekeeper's read_base. But why? its the same hardware clock for both tkr's. Surely if one goes funny the other

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied to the timekeeper's read_base. But why? its the same hardware clock for both tkr's. Surely if one goes funny the other

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Thu, Apr 02, 2015 at 10:36:47AM +0200, Peter Zijlstra wrote: Sure, struct timekeeper would work, the debug code already references the global tk_core to access that. While looking at that, the comment near tk_core says: /* * The most important data for readout fits into a single 64 byte *

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Peter Zijlstra
On Thu, Apr 02, 2015 at 09:51:51AM +0200, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied to

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread Ingo Molnar
* Peter Zijlstra pet...@infradead.org wrote: On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied to the timekeeper's read_base. But why? its the same hardware clock

Re: [PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-02 Thread John Stultz
On Thu, Apr 2, 2015 at 12:51 AM, Ingo Molnar mi...@kernel.org wrote: * Peter Zijlstra pet...@infradead.org wrote: On Wed, Apr 01, 2015 at 08:34:41PM -0700, John Stultz wrote: Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied

[PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-01 Thread John Stultz
Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied to the timekeeper's read_base. Thus this patch implements that suggestion. I'm a little hesitant here, since the tkr structure has been carefully designed to fit in a cacheline.

[PATCH 21/21] time: Rework debugging variables so they aren't global

2015-04-01 Thread John Stultz
Ingo suggested that the timekeeping debugging variables recently added should not be global, and should be tied to the timekeeper's read_base. Thus this patch implements that suggestion. I'm a little hesitant here, since the tkr structure has been carefully designed to fit in a cacheline.