On 6/28/13 3:09 AM, Peter Zijlstra wrote:
Yah! :-) Obviously doing a wakeup while holding scheduler locks isn't going to
work out well. And the only reason we really need that pesky softirq nonsense
is when we accidentally schedule a timer that's already expired; in that case
we'll run it from s
On Fri, Jun 28, 2013 at 11:00:21AM +0200, Ingo Molnar wrote:
> I guess we could merge this fix?
---
Subject: sched: Fix HRTICK
David reported that the HRTICK sched feature was borken; which was enough
motivation for me to finally fix it ;-)
We should not allow hrtimer code to do softirq wakeups
On Thu, Jun 27, 2013 at 04:28:57PM -0600, David Ahern wrote:
> On 6/27/13 4:43 AM, Peter Zijlstra wrote:
> >On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> >>On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> What is the expectation that the feature provides? not a whole lot of
> do
* David Ahern wrote:
> On 6/27/13 4:43 AM, Peter Zijlstra wrote:
> >On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> >>On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> What is the expectation that the feature provides? not a whole lot of
> documentation on it. I walked down the
On 6/27/13 4:43 AM, Peter Zijlstra wrote:
On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
On 6/26/13 1:05 AM, Peter Zijlstra wrote:
What is the expectation that the feature provides? not a whole lot of
documentation on it. I walked down the path wondering if it solved an odd
proble
On Thu, Jun 27, 2013 at 12:18:04PM -0700, Andy Lutomirski wrote:
> Supposedly, on really new x86 systems, the TSC deadline timer is so fast
> to reprogram that this isn't worth it.
>From what I've heard its not all that fast. I should play with it sometime, my
SNB desktop actually has this thing.
On 06/27/2013 03:53 AM, Peter Zijlstra wrote:
> On Thu, Jun 27, 2013 at 12:43:09PM +0200, Peter Zijlstra wrote:
>> On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
>>> On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> What is the expectation that the feature provides? not a whole lot of
>
* Peter Zijlstra wrote:
> On Thu, Jun 27, 2013 at 12:43:09PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> > > On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> > > >>What is the expectation that the feature provides? not a whole lot of
> > > >>documen
On Thu, 2013-06-27 at 12:53 +0200, Peter Zijlstra wrote:
> On Thu, Jun 27, 2013 at 12:43:09PM +0200, Peter Zijlstra wrote:
> > On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> > > On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> > > >>What is the expectation that the feature provides? not
On Thu, Jun 27, 2013 at 12:43:09PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> > On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> > >>What is the expectation that the feature provides? not a whole lot of
> > >>documentation on it. I walked down the path
On Wed, Jun 26, 2013 at 10:46:33AM -0600, David Ahern wrote:
> On 6/26/13 1:05 AM, Peter Zijlstra wrote:
> >>What is the expectation that the feature provides? not a whole lot of
> >>documentation on it. I walked down the path wondering if it solved an odd
> >>problem we are seeing with the CFS in
On 6/26/13 1:05 AM, Peter Zijlstra wrote:
What is the expectation that the feature provides? not a whole lot of
documentation on it. I walked down the path wondering if it solved an odd
problem we are seeing with the CFS in 2.6.27 kernel.
Its supposed to use hrtimers for slice expiry instead of
On Tue, Jun 25, 2013 at 03:20:00PM -0600, David Ahern wrote:
> On 6/25/13 3:17 PM, Peter Zijlstra wrote:
> >On Tue, Jun 25, 2013 at 03:05:38PM -0600, David Ahern wrote:
> >>Peter/Ingo:
> >>
> >>I can reliably cause a deadlock in the scheduler by enabling the HRTICK
> >>feature. I first hit the prob
On 6/25/13 3:17 PM, Peter Zijlstra wrote:
On Tue, Jun 25, 2013 at 03:05:38PM -0600, David Ahern wrote:
Peter/Ingo:
I can reliably cause a deadlock in the scheduler by enabling the HRTICK
feature. I first hit the problem with 2.6.27 but have been able to reproduce
it with newer kernels. I have n
On Tue, Jun 25, 2013 at 03:05:38PM -0600, David Ahern wrote:
> Peter/Ingo:
>
> I can reliably cause a deadlock in the scheduler by enabling the HRTICK
> feature. I first hit the problem with 2.6.27 but have been able to reproduce
> it with newer kernels. I have not tried top of Linus' tree, so per
Peter/Ingo:
I can reliably cause a deadlock in the scheduler by enabling the HRTICK
feature. I first hit the problem with 2.6.27 but have been able to
reproduce it with newer kernels. I have not tried top of Linus' tree, so
perhaps this has been fixed in 3.10. Exact backtrace differs by releas
16 matches
Mail list logo
