I do all of my programming on a laptop. This is fine for most things, but anything that hits 100% CPU or GPU load for very long pushes the temperatures up farther than I’m comfortable with. For example, compiling the kernel peaks at 73°C, over 30C° above its typical idle temperature. This laptop, an IBM ThinkPad T41, has a great keyboard, durable construction, and not enough cooling for graphics heavy games like Quake or Doom nor CPU heavy tasks like compiling the kernel or searching the entire disk for a regular expression.
I don’t compile the kernel often so I am willing to trade off longer compile times for lower temperatures. There are blunt instruments like locking the CPU clock at a very low rate, but I just want to throttle a single task, not the whole laptop. My solution is a program I call dutycycle that runs a program with a given duty cycle, e.g., 1 second on, 1 second off is a 50% duty cycle. I plan on allowing the user to specify a duty cycle between 1% and 99%, a cycle time (e.g., 1 second cycle time with a 50% duty cycle is a half second on and a half second off), and perhaps temperature thresholds (e.g. stop above 65°C, resume below 50°C). For the last feature to be feasible, there needs to be a fairly standard way to access the temperature. I haven’t looked into this aspect yet.
What makes this possible is that child/background processes can be sent the STOP and CONT signals. The former pauses the process, the latter resumes it. This behavior appears to be the POSIX standard behavior so it should work on any program. I’ve verified that it works on find. Compiling the kernel will be my acid testcase.
Once the code is in working condition and I’ve done some testing, it will become a project on SourceForge.