Messages in this thread | | | From | Michael Nazzareno Trimarchi <> | Date | Tue, 21 Feb 2023 08:10:38 +0100 | Subject | Re: [RFC][PATCH 2/2] time: alarmtimer: Use TASK_FREEZABLE to cleanup freezer handling |
| |
Hi
On Tue, Feb 21, 2023 at 1:12 AM Thomas Gleixner <tglx@linutronix.de> wrote: > > Michael! > > On Mon, Feb 20 2023 at 22:32, Michael Nazzareno Trimarchi wrote: > > On Mon, Feb 20, 2023 at 10:18 PM Thomas Gleixner <tglx@linutronix.de> wrote: > >> * alarmtimer_fired - Handles alarm hrtimer being fired. > >> @@ -194,6 +196,8 @@ static enum hrtimer_restart alarmtimer_f > >> int ret = HRTIMER_NORESTART; > >> int restart = ALARMTIMER_NORESTART; > >> > >> + atomic_inc(&alarmtimer_wakeup); > >> + > > > > ptr->it_active = 0; > > if (ptr->it_interval) { > > atomic_inc(&alarmtimer_wakeup); > > si_private = ++ptr->it_requeue_pending; > > } > > > > Should I not go to the alarm_handle_timer? and only if it's a periodic > > one? > > Why? >
You are right. I will pay more attention to my reply.
Michael
> Any alarmtimer which hits that window has exactly the same problem. > > It's not restricted to periodic timers. Why would a dropped one-shot > wakeup be acceptable? > > It's neither restricted to posix timers. If a clock_nanosleep(ALARM) > expires in that window then the task wake up will just end up in the > /dev/null bucket for the very same reason. Why would this be correct? > > Hmm? > > <GRMBL> > > Michael > > > >> spin_lock_irqsave(&base->lock, flags); > > <SNIP>Tons of wasted electrons</SNIP> > > Can you please trim your replies? > > </GRMBL> > > Thanks, > > tglx
| |