lmbench

Just did a quick run of 'lmbench' just to see what it does. Don't take these results too seriously, since no thought went into collecting them.

beagleboard.0 (14.4 KB)

This is close to what Koen got some weeks ago. Was the
framebuffer on and what was the resolution?

Laurent

I was running Koen's kernel and file system, so that's not too surprising. Framebuffer was on with some apps up, including Xorg. 1024x768.

Jason Kridner <jkridner@gmail.com> writes:

I think you mean 90 mb/s of total real memory bandwidth, assuming
the real memory subsystem has not the same limitations as the CPU
and runs much faster. If we assume the SoC is close to max BW we
are talking 90 MB out of ~1GB/s, about 10%.

Laurent

Laurent Desnogues wrote:

I was running Koen's kernel and file system, so that's not too
surprising. Framebuffer was on with some apps up, including Xorg.
1024x768.

Assuming that was running at 60Hz, it would be stealing 90 MB/s of
your memory bandwidth.

I think you mean 90 mb/s of total real memory bandwidth, assuming
the real memory subsystem has not the same limitations as the CPU
and runs much faster. If we assume the SoC is close to max BW we
are talking 90 MB out of ~1GB/s, about 10%.

I mean that 1024*768*2*60 = 90M (*2 for 16bpp). The dispc uses burst
lengths of up to 16 words (configurable). How much this impacts
the bandwidth available to the CPU depends on details that I don't
know. Measuring it is of course easy; I just haven't done it.

Running my little memcpy test, I noticed large variation between runs.
The fastest version (combination of ARM and NEON) varies from 290 to
340 MB/s on an otherwise idle system (no framebuffer). The virtual
addresses are the same each time, and caching effects should be
minimal since I'm using 32MB buffers and cache-line aligned reads and
writes.

I guess I'll have to think of some more targeted tests if I want to
find out exactly what is happening.