Rockbox mail archiveSubject: Re: time to sleep?
Re: time to sleep?
From: Sven Karlsson <svenka_at_it.kth.se>
Date: Thu, 22 Aug 2002 14:22:01 +0200
> I suggest we make the scheduler a tad more advanced, rather than make each
thread more complex. So the thread code looks the same, but threads are not
scheduled until their sleep() or queue_wait() is complete.
Agreed, it is common practice for low-power realtime kernels to sleep when
_no_ threads are running. So the main effort should go into the scheduler.
However, it wouldn't hurt to make sure the threads sleep whenever possible.
(I'm not sure how knowledgeable you all are when it comes to kernels so bare
with me if I sound patronizing. It isn't my intention at all.)
Another commonly used optimization is to always sleep as long as possible,
i.e., to adjust the timers so that the next timer interrupt occurs when the
next thread is to be awaken.
Finaly, and this is actually the most important one. To minimize the power
spent in the CPU (and memory) you need to:
1. Write very efficient code. Every cycle wasted in vain is power wasted!
2. Do not access memory if not needed. Memory accesses actually take a lot
of power. There are a lot coding tips one can use to minimise the amount of
memory accesses performed here are a few:
* Use the "register" keyword whenever possible. This often misunderstood
keyword actually means that one cannot take the adress of a variable. This
means that the compiler can do a lot better optimizations since it knows for
sure that the variable cannot be aliased, i.e., it cannot for instace be
accessed through a pointer, and it is always safe to keep it allocated in a
register. This usually means that the compiler won't have to write registers
back to memory when entering /leaving basic blocks among other things.
* Use the "restrict" keyword whenever possible. This keyword was just
recently introduced into the ANSI C spec. It means that a pointer do not
alias with any other pointer and so the compiler can keep data read through
a pointer in register. However, one must be careful when using restrict as
it is up to the programmer to make sure there are no aliasing going on with
* Use the "const" keyword whenever possible. By forcing variables to be
const the compiler can often do better common-sub-expression elimination
since it knows that the variable won't change its value.
* Don't count on the compiler doing obvious optimizations for you. The
compiler might not "see" them. It is always a good idea to look at the
assembly code generated by the compiler. You might be surprised!
3. Never busy wait for a long time. Use interrupts or go to sleep.
4. Never use interrupts for short timeouts. If you know the timeout is just
a few microseconds then wait that amount of time using a loop and then busy
wait. This often consumes less power.
5. Don't touch IO chips if can avoid it. The busdrivers often consume a bit
of power. This also applies to a lesser degree to microcontroller on-chip
IO. Remember that IO devices consume a bit of power when being poked at.
IIRC LCDs consume a lot more power when you change the screen contents than
when they are static.
These are just a few suggestions. It all boils down to common sense really.
Received on 2002-08-22