[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o7porea9.ffs@tglx>
Date: Mon, 20 Feb 2023 08:23:26 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Michael Nazzareno Trimarchi <michael@...rulasolutions.com>,
John Stultz <jstultz@...gle.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Stephen Boyd <sboyd@...nel.org>, Arnd Bergmann <arnd@...db.de>,
Michael <michael@...isi.de>, kernel-team@...roid.com
Subject: Re: [RFC][PATCH 2/2] time: alarmtimer: Use TASK_FREEZABLE to
cleanup freezer handling
On Sat, Feb 18 2023 at 15:56, Michael Nazzareno Trimarchi wrote:
>
> I have changed the alarm test to check some corner case
Could you tell us please which test did you change and what the change is?
> periodic_alarm
> Start time (CLOCK_REALTIME_ALARM)[ 85.624819] alarmtimer_enqueue: called
> : 94:865096467
> Setting alarm for every 4 seconds
> Starting suspend loops
> [ 89.674127] PM: suspend entry (deep)
> [ 89.714916] Filesystems sync: 0.037 seconds
> [ 89.733594] Freezing user space processes
> [ 89.740680] Freezing user space processes completed (elapsed 0.002 seconds)
> [ 89.748593] OOM killer disabled.
> [ 89.752257] Freezing remaining freezable tasks
> [ 89.756807] alarmtimer_fired: called
> [ 89.756831] alarmtimer_dequeue: called <---- HERE
>
> I have the dequeue but not an enquee of the periodic alarm. I was
> thinking that create a periodic time of 4 seconds
> and have the first alarm on suspend will always guarantee the re-arm
> it but it's not working as I expect
Again. You are not telling what you expect. It depends on how the timer
is set up whether the timer is self rearmed or not.
Thanks,
tglx
Powered by blists - more mailing lists