On Wed, Jan 14, 2015 at 1:35 AM, Peter Zijlstra wrote:
> On Tue, Jan 13, 2015 at 01:33:29PM -0800, John Stultz wrote:
>> On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra wrote:
>> > On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
>> >> When calculating the current delta since the
On Wed, Jan 14, 2015 at 1:35 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Jan 13, 2015 at 01:33:29PM -0800, John Stultz wrote:
On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating
On Tue, Jan 13, 2015 at 01:33:29PM -0800, John Stultz wrote:
> On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra wrote:
> > On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
> >> When calculating the current delta since the last tick, we
> >> currently have no hard protections to prevent
On Tue, Jan 13, 2015 at 01:33:29PM -0800, John Stultz wrote:
On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections
On Wed, Jan 14, 2015 at 10:33 AM, John Stultz wrote:
>
> So since this is a time reading function, this could be called
> anywhere.
Indeed. Could, and is.
>From within the scheduler, with some very core locks held. From within
printk itself (more really core locks held). From the tracer (which
On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra wrote:
> On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
>> When calculating the current delta since the last tick, we
>> currently have no hard protections to prevent a multiplciation
>> overflow from ocurring.
>>
>> This patch
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
> When calculating the current delta since the last tick, we
> currently have no hard protections to prevent a multiplciation
> overflow from ocurring.
>
> This patch introduces such a cap that limits the read delta
> value to the
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This patch introduces such a cap that limits the read delta
value to the max_cycles
On Wed, Jan 14, 2015 at 10:33 AM, John Stultz john.stu...@linaro.org wrote:
So since this is a time reading function, this could be called
anywhere.
Indeed. Could, and is.
From within the scheduler, with some very core locks held. From within
printk itself (more really core locks held). From
On Tue, Jan 13, 2015 at 3:11 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This
On Mon, Jan 12, 2015 at 09:30:07PM +0100, Richard Cochran wrote:
> On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
> > You say the tick should be scheduled before the clocksource wraps -
> > but we have logic to do that.
>
> Well that is a shame.
Arg, I mean, not a shame that we
On Tue, Jan 13, 2015 at 08:02:53AM +1300, Linus Torvalds wrote:
> Indeed. It's making things more robust in the face of _known_ issues.
> Even with a perfectly designed timer (which we so far have never
> seen), interrupts get delayed etc, so trying to stretch it to the
> limit of the timer is
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
> On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran
> wrote:
> > On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
> >> When calculating the current delta since the last tick, we
> >> currently have no hard protections to
On Tue, Jan 13, 2015 at 7:54 AM, John Stultz wrote:
>
> So I disagree this is papering over the problem.
Indeed. It's making things more robust in the face of _known_ issues.
Even with a perfectly designed timer (which we so far have never
seen), interrupts get delayed etc, so trying to stretch
On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran
wrote:
> On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
>> When calculating the current delta since the last tick, we
>> currently have no hard protections to prevent a multiplciation
>> overflow from ocurring.
>
> This is just
On Tue, Jan 13, 2015 at 7:54 AM, John Stultz john.stu...@linaro.org wrote:
So I disagree this is papering over the problem.
Indeed. It's making things more robust in the face of _known_ issues.
Even with a perfectly designed timer (which we so far have never
seen), interrupts get delayed etc,
On Mon, Jan 12, 2015 at 09:30:07PM +0100, Richard Cochran wrote:
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
You say the tick should be scheduled before the clocksource wraps -
but we have logic to do that.
Well that is a shame.
Arg, I mean, not a shame that we have logic
On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote:
On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard
On Tue, Jan 13, 2015 at 08:02:53AM +1300, Linus Torvalds wrote:
Indeed. It's making things more robust in the face of _known_ issues.
Even with a perfectly designed timer (which we so far have never
seen), interrupts get delayed etc, so trying to stretch it to the
limit of the timer is simply
On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran
richardcoch...@gmail.com wrote:
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
> When calculating the current delta since the last tick, we
> currently have no hard protections to prevent a multiplciation
> overflow from ocurring.
This is just papering over the problem. The "hard protection" should
be having a
On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote:
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This is just papering over the problem. The hard protection should
be having a tick
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This patch introduces such a cap that limits the read delta
value to the max_cycles value, which is where an overflow would
occur.
There was some
When calculating the current delta since the last tick, we
currently have no hard protections to prevent a multiplciation
overflow from ocurring.
This patch introduces such a cap that limits the read delta
value to the max_cycles value, which is where an overflow would
occur.
There was some
24 matches
Mail list logo
