On Wed, Oct 26, 2016, 12:54 PM Chris Murphy <lists@colorremedies.com> wrote:
On Mon, Oct 24, 2016 at 3:46 PM, Liam <liam.bulkley@gmail.com> wrote:

> Owen Taylor blogged about a few things that would be of use here (at least
> as far as GNOME apps go).
>
> https://blog.fishsoup.net/2014/10/23/perf-gnome-org-introduction/
>
> This discusses some perf tests run as part of CI.

I'd like to know, even if it's an informal survey, what percent of
Fedora developers (and separately, users), are using a laptop. This
perf tests mention desktop hardware. Yesterday on #fedora-kernel I
learned upstream isn't doing much laptop testing. So at the moment it
sounds like to me a bulk of the laptop testing happens once something
goes in updates-testing.


> https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

It'd be neat if it were possible to cross reference performance
regressions with packages, and somehow opt into getting a slower
release of packages with a higher performance regression rate. Sort of
a performance regression trustworthiness measure.

Separate, but related, I think it's currently a problem for rpm-ostree
which doesn't permit a decoupling between a current tree and the
kernel, for example. It's all or nothing. If there's a 4 month period
where I need to use an older or newer kernel than what's in the
current release ostree deployments, I can't do that using Fedora's
sources. I'd have to setup my own ostree server to get around it.

I'm really concerned about regressions where laptops don't power off
or suspend when the lid is closed. This has come up before, I've read
about it on various lists, but only recently have I experienced it
myself. And I don't know how to get more resources for this but it
seems like to me the laptop and CPU manufacturer should have more
stake and resources in this than they do, and do more testing so
there's an early warning sign before someone ends up with a smoldering
backpack on an airplane.
Yeah, I've mentioned that issue to you (well, more about my laptop not resuming than it going note7).
Btw, there's supposed to be a couple of trips that sounds very triggered if the package exceeds a certain temp. One is called prochot and the other is thermtrip. I'd expect the battery would also include some similar features, as should the motherboard, but I've not found any reference to them.



> https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Power_profiling_overview
>
> On the Firefox side they've a page that addresses this issue and offer a few
> solutions (at one point, perhaps they still do, they regularly ran tests to
> check for power use).
>
>
> I'll also mention that osx includes a panel, in the system monitor app, that
> will last and blame apps based on energy use. In the same app osx also
> offers a sysprof-like tool that allows you to see what calls are happening
> (since I'd imagine that it's using dtrace it may offer a great deal more
> than that but I've not dug into it).

Yea it's neat. It blames services too, not just user visible programs.
If you run any web browser though, that will far and away exceed
almost anything else other than a compiling, rasterizing, or anything
video.
Yes, but it's something that would make it easier for a user to quickly narrow down problems. That was really my point (obviously poorly phrased).
It also might be useful to show the user CPU and package states (parsed for the user, if need be, to something like ludicrous speed, or even PLAID, when you'd normally expect lightspeed---whatever, just as long as it's clear where on the scale they are) as that's a great way to determine how well their system is doing since Joules are basically meaningless without reference to their system's baseline (which their installation of Fedora may never approach).