linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Joel Fernandes <joelaf@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Tri Vo <trong@android.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Sandeep Patil <sspatil@android.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Hridya Valsaraju <hridya@google.com>,
	Linux PM <linux-pm@vger.kernel.org>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Alexei Starovoitov <ast@fb.com>
Subject: Re: Alternatives to /sys/kernel/debug/wakeup_sources
Date: Wed, 19 Jun 2019 14:01:36 -0400	[thread overview]
Message-ID: <CAJWu+ookFTYGfSvJ3otpFQixG2kbkJGOqf7HHUeYNQAQv2Cskw@mail.gmail.com> (raw)
In-Reply-To: <20190619170750.GB10107@kroah.com>

On Wed, Jun 19, 2019 at 1:07 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jun 19, 2019 at 12:53:12PM -0400, Joel Fernandes wrote:
> > > It is conceivable to have a "wakeup_sources" directory under
> > > /sys/power/ and sysfs nodes for all wakeup sources in there.
> >
> > One of the "issues" with this is, now if you have say 100 wake up
> > sources, with 10 entries each, then we're talking about a 1000 sysfs
> > files. Each one has to be opened, and read individually. This adds
> > overhead and it is more convenient to read from a single file. The
> > problem is this single file is not ABI. So the question I guess is,
> > how do we solve this in both an ABI friendly way while keeping the
> > overhead low.
>
> How much overhead?  Have you measured it, reading from virtual files is
> fast :)

I measured, and it is definitely not free. If you create and read a
1000 files and just return a string back, it can take up to 11-13
milliseconds (did not lock CPU frequencies, was just looking for
average ball park). This is assuming that the counter reading is just
doing that, and nothing else is being done to return the sysfs data
which is probably not always true in practice.

Our display pipeline deadline is around 16ms at 60Hz. Conceivably, any
CPU scheduling competion reading sysfs can hurt the deadline. There's
also the question of power - we definitely have spent time in the past
optimizing other virtual files such as /proc/pid/smaps for this reason
where it spent lots of CPU time.

> And how often does this happen?  Does it _need_ to happen?

These are good questions and we should find out. I am not saying that
sysfs will not work, I am just saying we need to consider all the
things. I will let Tri look into this since he is working on it, I
don't know off the top.

> Parsing files is also hard, and not for sysfs files, you can't have it
> both ways.

I don't think we are concerned with a parsing issue here, or are
discussing it in this thread.

> So try it this way, and if there really is a performance issue, we can
> then talk about it...

Sure that sounds good to me, again I am not saying we should do sysfs.
But we should consider all the issues and chose the right solution.

thanks!

 - Joel

  reply	other threads:[~2019-06-19 18:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05  0:23 Alternatives to /sys/kernel/debug/wakeup_sources Tri Vo
2019-06-11 17:31 ` Tri Vo
2019-06-18 20:17   ` Sandeep Patil
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 [this message]
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 publicly 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=CAJWu+ookFTYGfSvJ3otpFQixG2kbkJGOqf7HHUeYNQAQv2Cskw@mail.gmail.com \
    --to=joelaf@google.com \
    --cc=ast@fb.com \
    --cc=ast@kernel.org \
    --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=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rostedt@goodmis.org \
    --cc=sspatil@android.com \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).