Results 1 to 10 of 21

Thread: Linux Kernel Power Consumption Is Lowered, But Regressions Remain

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,399

    Default Linux Kernel Power Consumption Is Lowered, But Regressions Remain

    Phoronix: Linux Kernel Power Consumption Is Lowered, But Regressions Remain

    As discovered by a Phoronix reader, there is a patch in the Linux 2.6.39.1 kernel that can partially improve the system's power performance. The patch by a Nokia engineer is entitled "cpuidle: menu: fixed wrapping timers at 4.294 seconds" and initial reports have said that it will lower the power consumption compared to the stock 2.6.39 kernel.

    http://www.phoronix.com/vr.php?view=16104

  2. #2
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    How comes bisecting is taking so long? Having a very broad window (at commit-per-commit basis) and lowering it constantly should narrow it down very fast, right?

  3. #3
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by V!NCENT View Post
    How comes bisecting is taking so long? Having a very broad window (at commit-per-commit basis) and lowering it constantly should narrow it down very fast, right?
    micheael wrote it on zwitter some kernel versions are broken and this stops you in bisecting.

    bisecting is only fast if every version you generate works but what is if you only generate not working versions?

  4. #4
    Join Date
    Oct 2009
    Location
    .ca
    Posts
    406

    Default

    Yeah but it's taken a bit too long now?!
    Last concrete finding was that the offending commits that messed up 2.6.38 were from 13-15 January. And unfortunatly that one is not fixed in 2.6.39.1. Perhaps Micheal should have focused on one regression at a time...

  5. #5
    Join Date
    Jan 2009
    Posts
    1,737

    Default

    How comes bisecting is taking so long? Having a very broad window (at commit-per-commit basis) and lowering it constantly should narrow it down very fast, right?

    i blame the Bavarians
    Last edited by 89c51; 06-08-2011 at 08:21 PM.

  6. #6

    Default

    Reasons why it's taking so long to bisect:

    1. Needing to manually plug/unplug power adapter...
    2. Still haven't received (or otherwise figured out) any sub-$100 USB UPS/power-meter units for automatic power monitoring so fast desktop/workstations can be used for bisecting in a fully automated manner...
    3. Haven't been motivated by any ISVs or IHVs -- i.e. even any communication from them about correlating our bug detecting efforts. The only ISV communication has been from an interested (and totally independent) company offering up a 48-core system if it means bisecting can be done faster, but it's behind a corporate firewall and there is no power metering...
    4. Due to all of the involved work, it will be a number of articles in order to offset my expenses....
    5. Phoronix is pretty much just me doing all the work... I also need to be producing other content as well on a daily basis.
    6. Yes, the Bavarian visitors/friends did insert an additional few day delay.
    etc...

  7. #7
    Join Date
    Feb 2008
    Location
    USA
    Posts
    192

    Default

    Quote Originally Posted by Qaridarium View Post
    micheael wrote it on zwitter some kernel versions are broken and this stops you in bisecting.

    bisecting is only fast if every version you generate works but what is if you only generate not working versions?
    Code:
    $ git bisect skip
    ?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •