lkml.org 
[lkml]   [2001]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: graphical swap comparison of aa and rik vm
Date
I think the answer of why AA's kernel beat rik's has nothing to do with how 
much swap rik is using or how much swap is being swapped back in. It has to
do with how rik decides what to swap. Apparently the algorithm used by rik
to play with memory is taking seriously too much cpu and it leaves little for
the actual process to work. Thus AA's less cpu intensive code allows the
program to actually run and despite making errors in what to swap-out, the
process finishes well before Rik's more intelligent code.

Unfortunately, the trailing columns in my aa vmstat somehow got lost during
the paste from terminal buffer to file. This means i'm going to have to redo
it all in order to get an accurate measurement to compare system cpu time to
the rik vm. But for now i think the rik vm system graph is sufficient. And
there are some numbers from the AA vmstat and those alone show a much lower
cpu usage than in rik's. MUCH.

I made an overlay of Rik's system ( kernel ) cpu usage on top of the so and
si graphs to illustrate this. Bottom being 0% top being 100% usage.

http://safemode.homeip.net/sys_so.png
Here we see that after every major write out, there is major kernel cpu
usage. This is serious usage, and this is the reason why rik's VM loses the
race even though it swapped out and in the right things the first try more
often than AA's.

http://safemode.homeip.net/sys_si.png
Of course after each major write out in Rik's vm there is a minor read in.
These happen to be directly under the cpu spikes so this could be the cause
of the cpu usage, perhaps determining where the page is? I dont know enough
about what's going on in the code to figure out if the VM does something
after writing out that could be using all that cpu or if whenever it needs to
read in. Although now that i look at it i'm tending to lean towards some bad
code dealing with swap -> ram.

This is truly where the simple vm design conquers the complex. Less cpu being
used by the kernel means more by the program, and sometimes the time gained
by not using a lot of cpu greatly outweighs the time lost by having to
correct mistakes with deciding what gets swapped in and out.

Maybe i'm wrong as to the cause of the kernel cpu usage, but from the numbers
i do have from AA's vmstat, they are much higher in Rik's vm than in
Andrea's. That and the fact that Rik's vm seems to be doing the right thing
whereas Andrea's is having to fix mistakes yet Rik's loses seems to tell you
that i'm not wrong in thinking that it's the vm's cpu usage that is the
culprit.
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.059 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site