* 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
* 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
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
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
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
* 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
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
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
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
*
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
* 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
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
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.
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.
14 matches
Mail list logo