OpenBSD Journal

Hackathon 2005: Bob Beck reports on idle loop improvement.

Contributed by sean on from the when you got nothing better to do... spin dept.

Noryungi points out:

An interesting report from Bob Beck has been posted on KernelTrap.org. It seems that, while chasing problems on RAID performances, the merry hackers of the hackaton have been able to correct several problems in the OpenBSD kernel idle loop... leading to performance improvements. A very interesting read.

(Comments are closed)


Comments
  1. By Anonymous Coward (60.225.120.80) on

    It sounds like they did some good work! :)

    Comments
    1. By Anonymous Coward (68.104.57.241) on

      was this stuff backed out with the sched stuff theo backed out?

      Comments
      1. By Brad (216.138.195.228) brad at comstyle dot com on

        No.

  2. By Anthony Roberts (68.145.103.21) on

    What versions are affected? I remember testing performance of a new SATA drive some time ago. I got about 50 mb/s at the time, it's about 30 now with 3.7. That might have been 3.5 or 3.6, I don't remember when exactly I did it. If it's not this problem, it's something just as bad. I've also had "no buffer space available" errors.

    Will patches be released for stable releases?

    Comments
    1. By Nate (65.94.62.132) on

      I highly doubt it, in general only reliability and security issues get patches from OpenBSD, not performance. So you will have to wait till Fall for this performance boost or go to a snapshot after the hackathon. You could however create one if you were interested enough in the change, but then you'd pretty much be on your own if you messed it up and any developer interested in helping you would tell you to upgrade to the latest snapshot.

      Comments
      1. By Anthony Roberts (68.145.103.21) on

        With "no buffer space available" errors that require a reboot to resolve, it is a stability issue. As I didn't have that problem with 3.6, if there won't be a patch for 3.7 I will probably reinstall 3.6 and wait for the next stable. I have zero interest in running current.

        Comments
        1. By Brad (209.5.161.201) brad at comstyle dot com on

          You didn't even mention what network card(s) you're using. If you expect people to help you then you could file a useful bug report. This requires a dmesg at the minimum.

          Comments
          1. By Anthony Roberts (68.145.103.21) on

            I know. This is an informal forum and nothing I say here should be considered a bug report. I've been pretty busy lately. I'd prefer to wait a little while and do a proper bug report rather "my network stops working, here's a dmesg, please debug from scratch and get back to me with a fix". I would want to skim the docs to confirm I'm not doing anything stupid, turn off my tweaks, see if I can reliably reproduce it, etc.

      2. By Brad (209.5.161.201) brad at comstyle dot com on

        The locore diff goes beyond just performance improvements. For example this allows suspend/resume to work on my laptop (IBM T41) reliably, where as without it I cannot resume my laptop without having the OS lock up. The diff will be commited to -stable and have errata.

        Comments
        1. By Anthony Roberts (68.145.103.21) on

          This is good news. :)

    2. By Anonymous Coward (142.166.106.18) on

      Those of you who are perceptive might notice it has already been updated in -patch branch. I only checked out for 3.6 ... not sure about earlier versions. -

      Comments
      1. By rene (138.217.63.30) on

        are you sure about this? I have not checked the source files, but the developers are generally _very_ conservative about merging newly developed and relatively untested diffs into a -stable branch...

        Comments
        1. By Brad (209.5.161.201) brad at comstyle dot com on

          Seeing as I'm the maintainer of -stable I would know if this has been merged or not and it definitely has NOT been merged in yet. Soon enough though.

          Comments
          1. By Anonymous Coward (131.202.168.108) on

            I can't see how I could have made a mistake. I did a CVS update from anoncvs@anoncvs.nyc.openbsd.org:/cvs for OpenBSD 3.6 stable. Unless I've goofed (which is possible!) The locore.s was updated May 25, 2005.

            Comments
            1. By tedu (209.5.161.201) on

              go look at http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/i386/locore.s and find the OPENBSD_3_6 tag. no commits on May 25.

              Comments
              1. By Anonymous Coward (131.202.168.108) on

                Well, I must be confused in some way then. My bad ... sorry for the disinformation guys.

    3. By Matt (195.92.109.20) on

      for the impatient:

      in the /sys/arch/i386/i386 directory...
      update apm.c to 1.65.
      update locore.s to 1.89, but remove the change from 1.87 to 1.88.
      update mptramp.s to 1.3.

  3. By Yusuf Goolamabbas (61.10.7.21) on

    So, was this an issue only on i386 boxen. My reading of the KT article seems to indicate that AMD64 boxen would see no changes from the idle-loop improvement or am I wrong ?

    Comments
    1. By Anonymous Coward (209.5.161.201) on

      amd64 is fine

  4. By Anonymous Coward (66.92.213.187) on

    Wow this is super cool! I cant wait for 3.8! I know my $20 contributions are going to a good cause! If only they could have quaterly hackathons.... :|

  5. By Markus Hennecke (80.144.233.5) on

    Upgrading my Athlon XP box to 3.7 had a strange effect on the cpu temperature while idle. I am using fvcool to enable the chipset for C2 powersaving mode, this decreased cpu temperature to ca. 36°C. After upgrading to 3.7 I get 41°C as the lowest value. The box has Windows 2000 installed as a second os and I see the same temperature as in OpenBSD 3.6, so it is no hardware problem.
    Am I the only one seeing this effect? I did not have the time to look through the changes to find the cause of this, though.

  6. By Daniel Tams (83.72.196.169) on http://dantams.sdf-eu.org/

    Apropos improving idle loops, can anyone tell me if this article over at developerworks is genuine or if it's an April Fool's joke, given that it was published on April 1st?

    I have always thought it was an April's Fools joke, as I thought there is no use in optimizing the idle loop, as it is supposed to kill time. But given this new article on the same subject, and the fact that there is no slightest hint in the article that it is a joke, I would like to know for sure.

    Comments
    1. By Jim (198.62.124.245) on

      Think of it this way. Would you like a system that does the equivalent of sleep(100) or sleep(10) when it has nothing better to do? The first requires you to wait on average 50 before returning while the second requires an average wait of 5... I'm not saying that the idle loop is a sleep, just generalizing it. The CPU does not turn off in the idle loop. Read the code in the article and compare it to the oBSD source.

  7. By Anonymous Coward (66.110.114.5) on

    I have a Dell C800 laptop.
    Before the commit, It used to reboot and do a nice halt (no powerdown), but after the commit it doesn't even reboots freezing on the "rebooting" message.
    Question is: how to debug if the problem is the code, me or the laptop itself?

    Comments
    1. By tedu (209.5.161.201) on

      back it out and test? file a real bug report?

      Comments
      1. By Anonymous Coward (66.110.114.5) on

        Well, I've already backed it up, and it works again.

        I surely want to fill a PR about this, but I don't know how to technicaly describe the error.
        As I have told, it hangs in the "rebooting..." line. I don't have any
        idea of how to get any more information from the kernel. Please point
        me to some docs related to this so I can try getting this and fill the PR.

        Comments
        1. By pedro (209.5.161.201) on

          http://www.openbsd.org/report.html

  8. By m0rf (68.104.57.241) on

    speaking of the hackathon, pedro@ has committed changes removing the stackable filesystems (mount_union, mount_null and friends).

    Comments
    1. By Anonymous Coward (80.56.207.237) on

      What was the reason to remove it? At least nullfs has been very useful to me in the past.

      Comments
      1. By pedro (209.5.161.201) on

        look at the changelog of all the free operating systems

        or, preferably, look at the code itself

        Comments
        1. By Anonymous Coward (71.0.126.14) on

          I am not finding a "why" for all of this. Can you please provide a link or something?

          Comments
          1. By pedro (209.5.161.201) on

            sure

            http://ambientworks.net/~pedro/why.tgz

            Comments
            1. By Sam (130.88.31.6) on

              cute

    2. By Anthony Roberts (68.145.103.21) on

      I used a read-only null mount to put some stuff in my httpd jail... is there an alternative to that?

      Comments
      1. By tedu (209.5.161.201) on

        symlink into it.

        Comments
        1. By Anthony Roberts (68.145.103.21) on

          I was doing it for a repository of files way too big to fit in /var, so a symlink wouldn't help unless it was a symlink to somewhere outside of the chroot, and I didn't want to disable that.

          I left extra space on the disk when I partitioned it, but that was long ago. I was fortunate to have a partition that was big enough and that I didn't need anymore, I'm curious what a better way is for next time.

      2. By Matt (213.208.100.201) on

        NFS might work:

        mount -t nfs -o ro localhost:/stuff .../httpd/.../stuff

        or something like that. Not sure about the performance though, or stability. I was going to check it out at the weekend.

      3. By m0rf (68.104.57.241) on

        maybe we need to work to bring something like FiST into the ports tree.

      4. By Simon (130.225.194.192) on

        You could use a seperate partition and just mount that within the httpd chroot. It requires better planing of your disk usage of cause, but I believe that it's a much nice solution in the long run. Which mount_null and mount --bind in Linux, people often end up with incomprehensible filesystem layouts.

        Maybe it's good that union and null are gone, maybe it will force people to plan their filsystem layout better.

        Comments
        1. By Matt (195.92.109.20) on

          I'm not sure either way. Planning is clearly good, unfortunately in the real world things do crop up.

          Getting NFS exports to behave is another problem in which I would like flexibility.

        2. By mirabile (213.196.240.143) on http://MirBSD.org/

          People will just go back to using only / and swap.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]