Re: A desktop environment[1] kernel wishlist

[Chirantan Ekbote <chirantan@chromium.org>]

On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> On Thu, Apr 30, 2015 at 10:10 AM, John Stultz <john.stultz@linaro.org> wrote:
>> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera <hadess@hadess.net> wrote:
>>> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote:
>>>> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera <hadess@hadess.net>
>>>> wrote:
>>>> > Hey,
>>>> >
>>>> > GNOME has had discussions with kernel developers in the past, and,
>>>> > fortunately, in some cases we were able to make headway.
>>>> >
>>>> > There are however a number of items that we still don't have
>>>> > solutions
>>>> > for, items that kernel developers might not realise we'd like to
>>>> > rely
>>>> > on, or don't know that we'd make use of if merged.
>>>> >
>>>> > I've posted this list at:
>>>> > https://wiki.gnome.org/BastienNocera/KernelWishlist
>>>> >
>>>> > Let me know on-list or off-list if you have any comments about
>>>> > those, so
>>>> > I can update the list.
>>>>
>>>> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
>>>> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
>>>> documentation'
>>>>
>>>> Can you expand more on the rational for the need here? Is this for UI
>>>> for power debugging, or something else?
>>>
>>> This is pretty much what I had in mind:
>>> https://www.chromium.org/chromium-os/chromiumos-design-docs/lucid-sleep
>>>
>>> I guess I didn't make myself understood.
>>
>> My, admittedly quick skim, of that design document seems to suggest
>> that lucid sleep would be a new kernel state. That would keep the
>> kernel in charge of determining the state transitions (ie:
>> SUSPEND-(alarm)->LUCID-(wakelock
>> release)->SUSPEND-(alarm)->LUCID-(power-button)->AWAKE). Then it seems
>> userspace would be able to query the current state. This avoids some
>> of the races I was concerned with trying to detect which irq woke us
>> from suspend from userspace.
>>

Tomeu has been working on making things so that we don't need a new
kernel state.  Adding him on cc so he can correct me if I say
something wrong.  The current idea is to have userspace runtime
suspend any unneeded devices before starting a suspend.  This way the
kernel will leave them alone at resume.  This behavior already exists
in the mainline kernel.  Getting the wakeup reason can be accomplished
by having the kernel emit a uevent with the wakeup reason.  This is
the only change that would be necessary.

>> That said, the Power Manager section in that document sounds a little
>> racy as it seems to rely on asking userspace if suspend is ok, rather
>> then using userspace wakelocks, so I'm not sure how well baked this
>> doc is.
>>

I'm not sure I understand what you are saying here.  If you're saying
that the kernel is asking userspace if suspend is ok, then I can say
that that's definitely not the case.  Currently from the kernel's
perspective a lucid sleep resume isn't really different from a regular
resume.  We have a hack in each driver that we care about that
basically boils down to an if statement that skips re-initialization
if we are entering lucid sleep.  If userspace tries to access that
device in lucid sleep, it just gets an error.  This has actually
caused us some headache (see the GPU process section of the doc),
which is why we'd like to switch to using the runtime suspend approach
I mentioned above.

If instead you're saying that the power manager needs to ask the rest
of userspace whether suspend is ok, you can think of the current
mechanism as a sort of timed wake lock.  Daemons that care about lucid
sleep register with the power manager when they start up.  The power
manager then waits for these daemons to report readiness while in
lucid sleep before starting another suspend.  So each daemon
effectively acquires a wake lock when the system enters lucid sleep
and releases the wake lock when it reports readiness to the power
manager or the timeout occurs.

>> Olof: Can you comment on who's working on that design doc?   Also the
>> discussion around using freezing cgroups separately to distinguish
>> between lucid and awake is interesting, but I wonder if we need to
>> make wakeup_sources/wakelocks cgroup aware, or has that already been
>> done?
>

Currently cgroup process management is handled by the Chrome browser
since the only processes we freeze are Chrome renderers.  A renderer
is basically a process that hosts the content for a single tab,
extension, plugin, etc.  Freezing occurs when the system is about to
enter suspend from the fully awake state and thawing occurs during the
reverse transition.  We've made no changes to the cgroup code and have
been using it as is.

>
> Sameer and Chirantan have both been deeply involved in that project,
> adding them on cc here.
>
>
> -Olof