Subject: Re: SA110 - Current status
To: None <port-arm32@NetBSD.ORG>
From: Mark Smith <mark@findon.demon.co.uk>
List: port-arm32
Date: 10/17/1996 20:07:17
In message <9610171140.ZM10202@warhol>
          Robert Black <r.black@ic.ac.uk> wrote:

> If you were to use this scheme during a context switch then for fairly typical
> large applications with 4MB of read-write mapped DRAM each you need to remap
> roughly 1024 pages of 512 cache lines. Assuming that on average you can purge
> 10 cache lines every microsecond (not an unreasonable estimate) this means that
> it takes you more than 50ms to purge a page. The standard BSD time-slice is
> 100ms so you could end up spending 50% of the CPU time in cache-flushing. For
> applications with huge data areas (eg raytracers or X) the situation would be
> much worse.

It won't because the data cache is a limited size (16K) so you can never
have more that amount to write back.

In the best case situation when there are no dirty cache lines in the memory
to be swapped out, each cache control instruction should take one 200MHz
cycle. You'll need two of these, clean and flush, for each 32 byte block
within the memory range plus an additional 2 instructions to make the loop
to do that for all blocks with a page, one of which is a branch. With your
example of 4MB:

((1+1+1+2)*4*1024*1024/32)/200E6 = 3.28ms

In the worst case, the time taken to do a complete cache clean (continuous 8
word burst writes), regardless of how many pages you're remapping, is:

(((2*8)+3)*16384/32)/32E6 = 30ms

This doesn't include page remapping or interrupt checking but a lot of this
will be done in parallel with the cache lines being written out through the
write buffer.

You may still argue that it's a third of the standard time-slice (so maybe
it needs to be increased) but since any pages that are being remapped have
to be clean, I don't think there is any way around it with the processing
mapping method in use.

The ideal, as has been suggested, would be to have all processes
simultaneously resident at different addresses within the virtual address
space. That would make context switching extremely fast - no cache worries
and no overheads for remapping pages of memory.

-- 
Mark Smith - Surrey, UK         ...http://www.findon.demon.co.uk/...
This message was posted via my private internet account. It doesn't represent
the position of any individuals or organisations with whom I may be linked.
... Blessed are the Greeks