Announcement

Collapse
No announcement yet.

The Linux Kernel Power Problems On Older Desktop Hardware

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by deanjo View Post
    I never said you might not be right, but you have not proved that it doesn't exist. You say "This power bug doesn't exist" which is an absolute answer with no possibility of any chance that you might be missing something or unable to replicate. The only one displaying arrogance is you with your self confidence that what ever results you come up with has to be the only and absolute right answer.
    Unable to replicate across many systems and many use cases, remember I have 0 bug reports and a few thousand users. This in itself is evidence against this "bug".

    What you fail to realize though is that the burdon of proof is not on me. It is not my responsibility to disprove that the bug exists, it is on Phoronix who initiated and continued these same baseless claims for months. I don't think that it is too much to ask for Phoronix to actually prove their theory after all this time by showing us the commit since the claim was made in the first article that it would be found "quickly".

    Instead all we have seen is more sensationalist journalism proclaiming that the sky is falling.

    Give us the commit.

    Comment


    • #32
      Originally posted by Artemis3 View Post
      Hey fewt, where are your tests that demonstrate the power usage across kernels has not changed? Until then, you have no right to discredit others.

      I hope to see more tests, with actual facts and science done, not petty bickering in a forum based on beliefs.
      We test every kernel release at Fuduntu with powertop, and have not seen a change that wasn't expected. We began testing starting with kernel 2.6.35, and the only "problem" we have found is that nmi watchdog needed to be turned off in 2.6.38 (it defaulted on) when on battery.

      We added this to Jupiter, and it's since been forgotten about.

      Comment


      • #33
        fewt, I gather you ran all your tests with your Mono app on? Have you considered that maybe the regressed component is something your app disables or otherwise affects?

        Comment


        • #34
          Originally posted by curaga View Post
          fewt, I gather you ran all your tests with your Mono app on? Have you considered that maybe the regressed component is something your app disables or otherwise affects?
          I'm not sure why you have chosen to call it out as a Mono app, unless you are trolling (which I hope is not the case).

          To answer your question though, yes I have run all tests with Jupiter. If you think about it though, that's how it's supposed to work.

          You wouldn't benchmark Windows battery life with the Windows power manager disabled, or set on high, that would be silly. The same applies here.

          The kernel doesn't dynamically tune itself, which is why it is necessary for tools like Jupiter and tuned to exist. This is "business as usual".

          As the kernel grows in size (new functionality, and even bug fixes) it should be expected that it would use more power over time, because the kernel does more work over time.

          It is not up to the kernel team to change the running configuration (dynamic tuning), as that would negatively impact a great many things. This function belongs in userland.

          Comment


          • #35
            Originally posted by fewt View Post
            What you fail to realize though is that the burdon of proof is not on me. It is not my responsibility to disprove that the bug exists,
            When you give an absolute answer saying something "doesn't exist" the burden of proof does become yours as well. If you were to say something like "I doubt that it exists", "I haven't seen any iron clad proof it exists", etc then you have no burden of proof as you are just giving an opinion which does still allow for the possibility to be there even though you have not seen any satisfactory evidence to prove otherwise.

            Comment


            • #36
              Originally posted by deanjo View Post
              When you give an absolute answer saying something "doesn't exist" the burden of proof does become yours as well. If you were to say something like "I doubt that it exists", "I haven't seen any iron clad proof it exists", etc then you have no burden of proof as you are just giving an opinion which does still allow for the possibility to be there even though you have not seen any satisfactory evidence to prove otherwise.
              Stop attempting to deflect, and just show us the commit.

              Comment


              • #37
                Is michael seeing things in all those graphs that I cannot?
                I too think that this 'bug' is a load of nonsense, and this article deffinately is.
                Phoronix on top form as usual.

                Deanjo you need to actually read what fewt has said in this thread and the bug report.
                There is little to no evidence of a possible bug and it also doesn't seem to affect the vast majority of users. My laptop actually seems to last a bit longer on the latest kernel!

                Comment


                • #38
                  DPMS off, display?

                  Michael,

                  Since this is a desktop you are testing, is the display hooked up on the power meter as well when testing the effect of DPMS off? The first graph doesn't show any measurable difference (I can't see where the DPMS off/on events are).

                  Also as mentioned several times, make sure you 'align' the tests, so you end up with the same amount of idle and non-idle periods for each system.

                  Comment


                  • #39
                    Originally posted by fewt View Post
                    Stop attempting to deflect, and just show us the commit.
                    I think you just did that in a previous comment, at least for one of them:

                    Originally posted by fewt View Post
                    We began testing starting with kernel 2.6.35, and the only "problem" we have found is that nmi watchdog needed to be turned off in 2.6.38 (it defaulted on) when on battery.
                    Since Michael and all others that are complaining about the performance regressions are not using your application they are affected by this change of default setting. Now, if you can dig in the history of your application to find out what else it started disabling after kernel 2.6.35 you will also solve the mistery of the "first major regression".

                    Comment


                    • #40
                      Originally posted by Ansla View Post
                      I think you just did that in a previous comment, at least for one of them:



                      Since Michael and all others that are complaining about the performance regressions are not using your application they are affected by this change of default setting. Now, if you can dig in the history of your application to find out what else it started disabling after kernel 2.6.35 you will also solve the mistery of the "first major regression".
                      My source is on SourceForge, if you think the "regression" is a "regression" you are free to analyze it.

                      Comment


                      • #41
                        Originally posted by deanjo View Post
                        When you give an absolute answer saying something "doesn't exist" the burden of proof does become yours as well. If you were to say something like "I doubt that it exists", "I haven't seen any iron clad proof it exists", etc then you have no burden of proof as you are just giving an opinion which does still allow for the possibility to be there even though you have not seen any satisfactory evidence to prove otherwise.
                        And when someone gives an absolute that it does exist? Phoronix has a burden that it's not living up to with this article. That graph makes UFO sightings look like sound science in comparison. Credibility is being lost here.

                        I think it's odd that you're going to such great lengths to ask fewt to justify his absolutes but turn a bind eye toward Phoronix, which is well known for sensationalist headlines and articles that frequently contain unjustified absolutes. IMO it's fair turnaround to use unjustified absolutes to refute unjustified absolutes. (Perhaps not productive, but fair none the less.)

                        I predict more silence from the Phoronix side which is usually what happens when someone makes a valid point.

                        Comment


                        • #42
                          As someone said before, it seems to me that the "big kernel power problem" is
                          due to the a different implementation of the cpufreq ondemand governor.

                          If you do a git log drivers/cpufreq/cpufreq_ondemand.c
                          you can see how many changes have been done on the cpu governor that is the default for many distros.

                          Just to mention one (more or less in the 2.6.36 release cycle):

                          Wed, 6 Oct 2010 20:54:24 +0000 (16:54 -0400)
                          commit 3f78a9f7fcee0e9b44a15f39ac382664e301fad5
                          [CPUFREQ] add sampling_down_factor tunable to improve ondemand performance

                          Adds a new global tunable, sampling_down_factor. Set to 1 it makes no
                          changes from existing behavior, but set to greater than 1 (e.g. 100)
                          it acts as a multiplier for the scheduling interval for reevaluating
                          load when the CPU is at its top speed due to high load. This improves
                          performance by reducing the overhead of load evaluation and helping
                          the CPU stay at its top speed when truly busy, rather than shifting
                          back and forth in speed. This tunable has no effect on behavior at
                          lower speeds/lower CPU loads.

                          This patch is against 2.6.36-rc6.
                          This patch should help solve kernel
                          bug
                          19672
                          "ondemand is slow".
                          You could test with another cpufreq governor to see if bug "magically"
                          appears (such as powersave that as not been modified since
                          2008-10-09).

                          Another test could be the "cpufreq-utils" package which is choosing
                          the "wrong" cpufreq governor.

                          Bye
                          Marco

                          Comment


                          • #43
                            Originally posted by fewt View Post
                            Unable to replicate across many systems and many use cases, remember I have 0 bug reports and a few thousand users. This in itself is evidence against this "bug".

                            What you fail to realize though is that the burdon of proof is not on me. It is not my responsibility to disprove that the bug exists, it is on Phoronix who initiated and continued these same baseless claims for months. I don't think that it is too much to ask for Phoronix to actually prove their theory after all this time by showing us the commit since the claim was made in the first article that it would be found "quickly".

                            Instead all we have seen is more sensationalist journalism proclaiming that the sky is falling.

                            Give us the commit.
                            fewt,

                            Have you noticed any difference when moving from 10.10 to 11.04 on the settings affecting power management. How do you explain the results Tom's Hardware got when comparing the two in terms of battery life ?

                            Comment


                            • #44
                              I'm just a noob, and can't reproduce the problem (I'm using 2.6.39-ck2), but why not give a try to a non smp kernel, other processes scheduler, kernel parameters (disabling all power management capabilities), etc.

                              Is it really impossible to reproduce the same power consumption between a pre- and post- bug kernel ?

                              It could exclude a lot of tracks, and help to fill a useful bug report.

                              In example, there's a scheduler parameter for power management on an smp system :
                              http://www.kernel.org/doc/Documentat...ces-system-cpu

                              What: /sys/devices/system/cpu/sched_mc_power_savings
                              /sys/devices/system/cpu/sched_smt_power_savings
                              Date: June 2006
                              Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
                              Description: Discover and adjust the kernel's multi-core scheduler support.

                              Possible values are:

                              0 - No power saving load balance (default value)
                              1 - Fill one thread/core/package first for long running threads
                              2 - Also bias task wakeups to semi-idle cpu package for power
                              savings

                              Comment


                              • #45
                                Originally posted by ioannis View Post
                                fewt,

                                Have you noticed any difference when moving from 10.10 to 11.04 on the settings affecting power management. How do you explain the results Tom's Hardware got when comparing the two in terms of battery life ?
                                I haven't tested Ubuntu 10.10 vs 11.04, as I haven't been involved with that distribution for some time. I wouldn't be surprised though that 11.04 was power hungry, as Unity is still in active development and is most likely not optimized for low power use.

                                Comment

                                Working...
                                X