Linux-PM Archive on lore.kernel.org
 help / color / Atom feed
From: Sandeep Patil <sspatil@android.com>
To: Tri Vo <trong@android.com>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org,
	Hridya Valsaraju <hridya@google.com>,
	linux-pm@vger.kernel.org, kernel-team@android.com,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org
Subject: Re: Alternatives to /sys/kernel/debug/wakeup_sources
Date: Tue, 18 Jun 2019 13:17:16 -0700
Message-ID: <20190618182502.GC203031@google.com> (raw)
In-Reply-To: <CANA+-vARQ9Ao=W1oEArrAQ0sqh757orq=-=kytdVPhstm-3E9w@mail.gmail.com>


Hi Rafael, Viresh etc.

On Tue, Jun 11, 2019 at 10:31:16AM -0700, Tri Vo wrote:
> On Tue, Jun 4, 2019 at 5:23 PM Tri Vo <trong@android.com> wrote:
> >
> > Hello Rafael,
> >
> > Currently, Android reads wakeup sources statistics from
> > /sys/kernel/debug/wakeup_sources in production environment. This
> > information is used, for example, to report which wake lock prevents
> > the device from suspending.

Android's usage of the 'wakeup_sources' from debugfs can is linked at[1].
Basically, android's battery stats implementation to plot history for suspend
blocking wakeup sources over device's boot cycle. This is used both for power
specific bug reporting but also is one of the stats that will be used towards
attributing the battery consumption to specific processes over the period of
time.

Android depended on the out-of-tree /proc/wakelocks before and now relies on
wakeup_sources debugfs entry heavily for the aforementioned use cases.

> >
> > Android userspace reading wakeup_sources is not ideal because:
> > - Debugfs API is not stable, i.e. Android tools built on top of it are
> > not guaranteed to be backward/forward compatible.
> > - This file requires debugfs to be mounted, which itself is
> > undesirable for security reasons.
> >
> > To address these problems, we want to contribute a way to expose these
> > statistics that doesn't depend on debugfs.
> >
> > Some initial thoughts/questions: Should we expose the stats in sysfs?
> > Or maybe implement eBPF-based solution? What do you think?

We are going through Android's out-of-tree kernel dependencies along with
userspace APIs that are not necessarily considered "stable and forever
supported" upstream. The debugfs dependencies showed up on our radar as a
result and so we are wondering if we should worry about changes in debugfs
interface and hence the question(s) below.

So, can we rely on /d/wakeup_sources to be considered a userspace API and
hence maintained stable as we do for other /proc and /sys entries?

If yes, then we will go ahead and add tests for this in LTP or
somewhere else suitable.

If no, then we would love to hear suggestions for any changes that need to be
made or we simply just move the debugfs entry into somewhere like
/sys/power/ ?

As a side effect, if the entry moves out of debugfs, Android can run without
mounting debugfs in production that I assume is a good thing.

- ssp

1. https://android.googlesource.com/platform/frameworks/base/+/refs/heads/master/core/java/com/android/internal/os/KernelWakelockReader.java#127

  reply index

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05  0:23 Tri Vo
2019-06-11 17:31 ` Tri Vo
2019-06-18 20:17   ` Sandeep Patil [this message]
2019-06-18 21:23     ` Rafael J. Wysocki
2019-06-18 23:15       ` Tri Vo
2019-06-18 23:52         ` Joel Fernandes
2019-06-19  8:35           ` Rafael J. Wysocki
2019-06-19 10:33             ` Joel Fernandes
2019-06-19 16:51             ` Sandeep Patil
2019-06-19 16:53             ` Joel Fernandes
2019-06-19 17:07               ` Greg Kroah-Hartman
2019-06-19 18:01                 ` Joel Fernandes
2019-06-19 18:31                   ` Tri Vo
2019-06-19 18:35                   ` Greg Kroah-Hartman
2019-06-19 18:55                     ` Joel Fernandes
     [not found]                       ` <CAGETcx-ZZRc_jtBws2cFTe1wjiWeBowdqfqOhcCJV_7AUyBEVw@mail.gmail.com>
2019-06-19 20:09                         ` Joel Fernandes
2019-06-19 20:40                           ` Saravana Kannan
2019-06-19 20:52                             ` Joel Fernandes
2019-06-24  1:48             ` Tri Vo
2019-06-24  7:36               ` Greg Kroah-Hartman
2019-06-24 12:27                 ` Joel Fernandes
2019-06-24 21:55                   ` Rafael J. Wysocki
2019-06-24 22:14                     ` Tri Vo

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190618182502.GC203031@google.com \
    --to=sspatil@android.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hridya@google.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=trong@android.com \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pm/0 linux-pm/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pm linux-pm/ https://lore.kernel.org/linux-pm \
		linux-pm@vger.kernel.org linux-pm@archiver.kernel.org
	public-inbox-index linux-pm


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pm


AGPL code for this site: git clone https://public-inbox.org/ public-inbox