My guess is that rik's vm allocates memory too relaxed. It quickly grabbed
all the memory it thought it would need so it wouldn't have to waste time
increasing or shrinking it (i guess that's why) and in doing so it started to
strangle memory needed for other things, generally decreasing the overall
performance of the system. That could be why you see spikes increasing and
decreasing rapidly in rik's vm allocation of swap. He had allocated
everything and needed to shrink it to make room for something else (actual
generation of the kde window for kghostview?) which caused it to lose much
time and any advantage it had gained by not making actual swap mistakes.
AA's memory allocation is more minimalistic but it easily has room for the
memory needed to render the kde window and all once processing the ps file
was done. This would also back up what i visually saw during the test.
Rik's kernel got done the processing of the ps file before AA's did, but it
was stuck at a frozen looking kghostview window with nothing inside it for a
while before being able to actually render the contents. AA's was able to
render the contents almost immediately after the window showed up on the
screen.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/