OpenBSD Journal

n2k13 update: Paul Irofti Talks Loongson and ACPI

Contributed by tbert on from the lets-do-the-time-warp-again dept.

Paul Irofti(pirofti@) tells us about the work he did at n2k13:
The n2k13 hackathon was mainly a Loongson hackathon for me. My main goal was to add CPU throttling support. A few things related to clocks needed to be implemented before being able to deal with the actual CPU scaling bits.
Paul continues:

First of all I needed to replace the system clock provided by the CPU with a multi-functional general purpose timer found on the Geode companion chip. CPU throttling was not possible due to the fact that the system clock was the CPU clock; slowing down the CPU would also slow down the passage of time.

My first commit added a driver for the MFGPT1 clock from the companion chip and hooked it up as the system clock. It also changed the frequency value of hz from the default, which was 100, to 128, because the scaling on MFGPT clocks is represented by powers of two.

The best thing about hackathons is that I get to talk to a lot of people that are a lot smarter than me and willing to share some of their knowledge with me. A good example is the talk I had with dlg@. Seeing I was working on clocks, he mentioned Torek's paper on statistical clocks and asked if we have support for that on the loongson platform. We did not. In fact, we didn't have any statistical clock on that platform. So the next thing I did was to add a stat clock for the lemote machines.

I implemented it so that it also covers, at least according to the tests I've done, Torek's paper on randomized sampling. Most of the bits for randomizing the stat ticks were taken from sparc's implementation and adapted to the companion chip's MFGPT frequencies.

Before this, my lemote showed a 8% cpu usage for the cpuhog example from Torek's paper even though openssl speed showed differences up to 27% when ran with and without cpuhog. With the new stat clock it shows cpuhog around 18-22%, which I think is the proper value.

After that, everything was in place for the CPU scaling bits to go in. I had an old diff from otto@ that I used as a source of inspiration, but after the clock changes it turned out everything had gotten a lot simpler and I wrote a shorter and much simpler diff with the help of miod@ that got committed shortly after.

So now OpenBSD 5.3 will ship with CPU scaling support on Loongson.

I also couldn't help myself and went back to look in the acpi(4) layer where I had some infrastructure bits that I wanted to put in the tree.

I added global lock enter and leave routines, which I think is the way to go if we want to have proper locking in our acpi drivers. It doesn't hook onto anything from the kernel yet and they're just building a framework towards locking.

Having that in the tree allowed me to add acpiec_lock and acpiec_unlock routines. The routines check if the AML requires us to acquire the global lock by checking a flag stored in the soft state at attach time and locks or unlocks if true.

Further testing is needed on multiple machines and configurations before the tree can take advantage of the above and I want to do start enabling bits of it for wide testing after the 5.3 release is out so that I can get it to a stable and reliable point, hopefully, for the 5.4 release.

In conclusion it was a very productive hackathon for me and I want to thank Jim Cheetham for making this event possible, Theo de Raadt and the OpenBSD Foundation for taking care of my flight and accommodation, and everyone that buys the CDs and donates keeping this wonderful project going!

(Comments are closed)


Comments
  1. By Anonymous Cowherb (anon) M8R-2m2huq@mailinator.com on

    A couple of things I wondered about this... Ignoring the HZ issue, would there be any advantage to using this on other systems with CS5536 (some Soekris/PC Engines boards)? Also, is this for a completely different purpose to the 3.5MHz timecounter that glxpcib(4) supports, or is it an alternative?

    Comments
    1. By Paul Irofti (bulibuta) on gopher://sdf.lonestar.org/1/users/bulibuta

      I guess there could be some use for an alternative stat clock for CS5536 boards that are found on i386 configurations. I don't know if that's really wanted nor how clean it would be to add that. I have thought of it as well, but it's not really on the top of my todo list.

      As for the driver itself it adds two clocks: a hardclock and a statclock.

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.]