Basically, I have a volume rendering application that bangs on the
memory subsystem quite a bit. Typical rendering times for my dataset
are around 6 seconds. If I stop using the renderer and fire up another
programme which manipulates an array larger than physical memory
(hence paging out code and data used in the renderer), quit that
programme and use the renderer again (after waiting for it's code and
data to page back in), the times go down to 4.9 seconds! Repeated
renders give the same time.
If I then exit the renderer and start it again, the times go back up
to around 6 seconds. Repeated renders also give the same time. I can
repeat the whole procedure of paging out the renderer and I get the
same results. This suggests that somehow the rendering times are
sensitive to the physical location of pages in RAM or the degree of
fragmentation. To my thinking, this shouldn't happen, and makes me
suspect either the OS or a defective implementation of the MMU.
Actually, I don't see what the OS has to do with it, since once my
pages are in RAM, it should have nothing to do with it. So that leaves
the MMU.
I don't expect that cache issues should be significant here, since the
dataset is much larger than cache (the volume is 13 MBytes). So that
leaves the MMU as my main suspect, although that seems unreal.
Is this something our UltraSparc gurus could comment on? Is it
Solaris, the MMU or something else?
System is an Ultra 170E with 64 MBytes of RAM.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/