From: Sven Karlsson <svenka_at_it.kth.se>
Date: Fri, 23 Aug 2002 00:11:05 +0200

Linus,

I wandered left and right trying to decide if this were going in a private
mail. However, after a bit poundering I wnt for the rude public way.

> Yes, they do. If you want fewer memory accesses you will have to use
> either a cache or sleep between the memory accesses. This is a RISC
> without a cache.

Please look at my initial post:
>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.

So, I'm all for using sleep modes. However, if you are really going to
reduce power then you should sleep as much as possible. And you cannot do
that if you are using inefficient code.

Now, code that usually is not considered inefficient can be very inefficient
if you look at the power usage. I gave some pointers to what I believe are
good programming standards.

Now arguing about caches is moot as you already pointed out yourself: there
aren't any. But then again, I never mentioned caches. First of all I know
that the SH used in the player and the recorder does not have any caches.
Second, caches have little to do with it. Now why is that?

The cache simply act as a filter for memory accesses and it is part of the
memory hierarchy. The reason the cache is there is so that the large latency
of the main memory can be somewhat hidden and so it can increase execution
throughput in a lot of cases. However, a cache actually adds to the power
consumption and ironically it is often better from a power point of view to
use very small caches. (At least small L1 caches. large L2 are often good if
they can be done slow enough, i.e., drawing a little power as possible). In
short, adding a cache doesn't automatically mean you will reduce the power
usage.

There are several good papers written on the subject. I suggest reading the
works of the students of Mary Jane Irvine and Margaret Martonosi. There are
also a few interesting ones written by a few collegues of mine that will be
published shortly.

Caches can in some cases help you but often not. They are basically only
useful from a low power point of view if they do not consume a lot of power
and you can fit all of your code in them or if most of your processing
cycles are run in a few rather small loops. Interrupts and switching between
shortly running threads tends to trash cache performance tremendously and in
practice makes them of no use. This is why you often see cache "freeze"
features in microcontrollers so you can make sure a few selected cache
blocks, i.e., interrupt handlers etc., are always in the the cache. In fact,
people tend to turn all caches of completely in hard real-time systems since
you cannot rely on their performance when running lots of critical
interrupts and threads.

What is, however, commonly agreed upon as a good thing as to save power is
using compiler optimizations to make short efficient code with few memory
references and writing efficient code.

You mention that the SH is a RISC. I should perhaps mention that IMO "RISC"
doesn't really mean anything. The SH is a load-store architecture and that
is much more important. RISC simply means that you only use the most basic
instructions so you can implement a pipelined version of the architecture in
rather little silicon area. And what does RISC have to do with power
consumption except that a pipelined processor tend to consume a little bit
more power than a multicycle processor? There are a few excellent text books
on the subject one of them are written by Hennessy and Pattersson (note the
order, not to be confused with Pattersson and Hennessy which is not by far
as good).

To me it looks like you believe I'm against using sleep mode. I'm not, never
was, and I frankly cannot see how you could deduce that.

I'm not looking for a fight. I do tend to be bit agitated, though, when
people are using arguments that I don't believe are true. I'm the first to
admit that I'm wrong all the time. However, this time I'm quite confident
I'm not.

Best regards
 Sven
Received on 2002-08-23