No, Thomas didn't yet push the fix.
27.12.2014, 02:34, "Stephen Boyd" :
> On 06/22/2014 07:46 AM, Thomas Gleixner wrote:
>>> + for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
>>> + ktime_t expires;
>> So this adds the third incarnation of finding the next expiring timer
>> to the code. Not rea
On 06/22/2014 07:46 AM, Thomas Gleixner wrote:
>> +for (i = 0; i < HRTIMER_MAX_CLOCK_BASES; i++) {
>> +ktime_t expires;
> So this adds the third incarnation of finding the next expiring timer
> to the code. Not really helpful.
>
> Untested patch which addresses the issues below.
We
> > Tested-by is fine. I can cobble a changelog together.
No issues after more than a day of running, I think you can use my
Tested-By: Stanislav Fomichev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordom
> So in case the enqueued timer is earlier than base0->next, you are
> looking at the wrong data. Same as in the current code and why you
> started to look into this at all.
Right, even if we do a local enqueue from higher base timer into lower base we
still need to update base->next in the enqueue
On Mon, 23 Jun 2014, Stanislav Fomichev wrote:
> >
> > + * @next: time of the next event on this clock base
> >
> > What initializes that? It's 0 to begin with.
> I thought I can skip initialization because I update base->next
> in the interrupt or in __remove_hrtimer, like:
> - enqu
Hi Thomas,
>
> + * @next: time of the next event on this clock base
>
> What initializes that? It's 0 to begin with.
I thought I can skip initialization because I update base->next
in the interrupt or in __remove_hrtimer, like:
- enqueue_timer, base->next is 0
- reprogram device
- d
On Wed, 19 Mar 2014, Stanislav Fomichev wrote:
+ * @next: time of the next event on this clock base
What initializes that? It's 0 to begin with.
> @@ -893,6 +895,10 @@ static int enqueue_hrtimer(struct hrtimer *timer,
>*/
> timer->state |= HRTIMER_STATE_ENQUEUED;
>
>
On Wed, 4 Jun 2014, Stanislav Fomichev wrote:
> Thomas, any estimate on when you'll be able to review this patch?
> It's been almost 3 months since is sent it. Is there any particular
> reason you don't want to pull it (because on my machines it's
> been working fine without any issues)?
It's in
Thomas, any estimate on when you'll be able to review this patch?
It's been almost 3 months since is sent it. Is there any particular
reason you don't want to pull it (because on my machines it's
been working fine without any issues)?
On Wed, Mar 19, 2014 at 06:16:15PM +0400, Stanislav Fomichev wr
> >Any comment on the v2?
>
> I'm traveling and it's in my todo list
Ping? It's been a while since you added it to your todo list :-)
Btw, I have a couple of machines that have been working without any
issues with this patch applied...
--
To unsubscribe from this list: send the line "unsubscribe
On 2014-03-24 09:42, Stanislav Fomichev wrote:
Hi,
Any comment on the v2?
I'm traveling and it's in my todo list
--
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/majo
Hi,
Any comment on the v2?
--
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/
I think I'm hitting particularly subtle issue with NOHZ_IDLE kernel.
The sequence is as follows:
- CPU enters idle, we disable tick
- hrtimer interrupt fires (for hrtimer_wakeup)
- for clock base #1 (REALTIME) we wake up SCHED_RT thread and
start RT period timer (from start_rt_bandwidth) for clo
13 matches
Mail list logo
