Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752716AbbD3Sy5 (ORCPT ); Thu, 30 Apr 2015 14:54:57 -0400 Received: from mail-qk0-f176.google.com ([209.85.220.176]:35118 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752546AbbD3Syw (ORCPT ); Thu, 30 Apr 2015 14:54:52 -0400 MIME-Version: 1.0 In-Reply-To: References: <1413881397.30379.7.camel@hadess.net> <1430411117.3945.2.camel@hadess.net> Date: Thu, 30 Apr 2015 11:54:51 -0700 X-Google-Sender-Auth: qABKbYUSpROGpVvVSA9qj3kVevc Message-ID: Subject: Re: A desktop environment[1] kernel wishlist From: Chirantan Ekbote To: Olof Johansson Cc: John Stultz , Bastien Nocera , "Rafael J. Wysocki" , Linux Kernel Mailing List , snanda@chromium.org, Tomeu Vizoso Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5055 Lines: 111 On Thu, Apr 30, 2015 at 10:23 AM, Olof Johansson wrote: > Hi, > > On Thu, Apr 30, 2015 at 10:10 AM, John Stultz wrote: >> On Thu, Apr 30, 2015 at 9:25 AM, Bastien Nocera wrote: >>> On Tue, 2014-10-21 at 10:04 -0700, John Stultz wrote: >>>> On Tue, Oct 21, 2014 at 1:49 AM, Bastien Nocera >>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/