Re: A desktop environment[1] kernel wishlist

[John Stultz]

On Tue, Oct 21, 2014 at 11:09 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
>> I suspect wakeup type reporting is maybe not the best way to go about
>> this, since there may be a number of causes for wakeups and they can
>> arrive closely together in different orders, which can result in
>> races.
>>
>> For instance, if the machine suspends, and sets an alarm to be woken
>> up at midnight to do a backup, if the user resumes their laptop at
>> 11:59:59, should the backup still proceed at midnight?
>
> No. And I would expect that we would get a wake up type of "power
> button" or "lid open" in this case.
>
>>   What happens
>> if the user starts to use their machine at 12:00:01?
>
> I would expect the backup to stop and be tried again later.

What "event" would you be using to trigger stopping the backup?


>>   What about if
>> the user walked away from their machine at 11:55:01, and the system
>> would suspend at 12:00:01, should the backup commence at 12:00:00?
>
> That wouldn't happen because we'd set the wake up time when suspending.
>
>> Thus you probably want to have a "user present" status,
>
> We can do any sort of thing once the laptop is awake. But right now
> there's no way to know whether the resume is due to a user action or
> not.

I'm suggesting its best if you don't care which specific irq brought
the device out of suspend mode.

You may want to monitor various events like the lid-open or
power-button (as well as the timerfd for alarms), and use those for
your logic, but again, because a number of different irqs might bring
the system out of suspend and those irqs can possibly occur almost
simultaneously, which specific one landed first and woke the system is
really not that useful (and again prone to races).

Now, I do think knowing which IRQ did bring you out of suspend is
useful, but mostly for power-debugging when you're trying to optimize
battery life. But for userland logic, I think its far too prone to
races.


>>  then use the
>> timerfd() ALARM clockids to set any wakeups you'd like, and when they
>> trigger (if the system was suspended or not), decide to do your backup
>> based the conditionals you had above, using the user-present status in
>> a similar way to how you use AC status.
>>
>> I'd suggest looking into some of the details on how Android does its
>> wakelock logic, as well as the timerfd ALARM clockids, since I think
>> this would provide what you need.
>
> It doesn't. There's still a whole class of hardware that isn't always on
> as mobile SoCs are, and wakelocks aren't going to help if the kernel
> isn't running and we don't know why it started running again.

I'm not sure I parsed this properly. Mobile SoCs are quite frequently
in suspend and not always on. They frequently resume both due to
wakeup alarms, modem call irqs, and as a result of user-interaction
like button presses.


>> My bigger concern here with your use case though, is that you might be
>> able to use ALARM timers more commonly, but that for much existing
>> hardware, corner cases like programmatic resuming of a laptop while
>> its packed in a bag somewhere might have thermal risks.
>
> I'm pretty sure that Windows has done this for years before we did. If
> the laptop cannot suspend reliably, then the user would disable it. We
> cannot keep designing around broken software.

Sure. But its not reliably suspending I'm worried about, its
accidentally resuming in an environment the hardware wasn't designed
for. Its really more of a hardware design issue. I'm not suggesting
you don't do it, but I just suspect you'll need to be careful about
automatically enabling this on older hardware.

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/