lmbench

[Jason Kridner]

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.

[Laurent Desnogues]

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

Laurent

[Jason Kridner]

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.

[Måns Rullgård]

Jason Kridner <jkri...@gmail.com> writes:

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

--
Måns Rullgård
ma...@mansr.com

[Laurent Desnogues]

On Wed, Sep 17, 2008 at 10:38 AM, Måns Rullgård <ma...@mansr.com> 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%.

Laurent

[Måns Rullgård]

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.

--
Måns Rullgård
ma...@mansr.com