graphical swap comparison of aa and rik vm

graphical swap comparison of aa and rik vm

[safemode]

In an earlier post i mentioned a way of locking up my vm easily and 
repeatedly but that has since been fixed in one way or another.  I reran the 
test and took vmstat 1 's of both runnings on a 2.4.14-pre6-preempt kernel 
and a 2.4.13-ac5-preempt kernel.  I began both vmstat's at the same time 
(about 4 seconds before running each).  What i did was run kghostview on a 
postscript file located here http://safemode.homeip.net/test.ps  .  It is 
224K.  kmail was loaded previously in both trials so kdeinit was already 
loaded as were all libs.   After kghostview became responsive, i waited a few 
seconds (again about 5) and then exited the app.  

No other interaction or running programs were present while doing this.  
I have 771580 KB of ram and 290740 KB of swap.

Now to explain the graphs.
The blue is AA's vm.  The red is Rik's vm.  Rik's vm finished in 66 seconds. 
AA's vm finished in 52 seconds.  Both start at 0 swap usage.  Both from clean 
boots.  

Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   . It's 
about 4.6K. 

When you look at the graph it goes like this. 
The left side is 0 seconds, the right side is 66 seconds.  bottom is 0KB, top 
is 290740KB.   

These are generated from data from the orignal vmstat outputs.  These are at 
http://safemode.homeip.net/aa_vmstat
and 
http://safemode.homeip.net/rik_vmstat 

I'll leave the actual interpretation of the data of both the graph and raw 
data up to those who actually know the code.  

Neadless to say that while running the test on either box, the entire 
computer became unresponsive multiple times for extended lengths of times.  
No OOM was generated on either run. 

Re: graphical swap comparison of aa and rik vm

[Alex Pennace]

On Wed, Oct 31, 2001 at 10:18:29PM -0500, safemode wrote:
> Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   . It's 
> about 4.6K. 

The server says, "Wrong file name fool."

Re: graphical swap comparison of aa and rik vm

[safemode]

On Wednesday 31 October 2001 22:41, Alex Pennace wrote:
> On Wed, Oct 31, 2001 at 10:18:29PM -0500, safemode wrote:
> > Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   .
> > It's about 4.6K.
>
> The server says, "Wrong file name fool."

Fixed it.   That's what you get  when you're creating the graph at the same 
time as writing the email.    Sorry to all.  it will work now. 

Re: graphical swap comparison of aa and rik vm

[safemode]

I decided it would be nice to see the actual swap io as well.   since 
allocating and writing and reading are two different things.  

http://safemode.homeip.net/si-swap.png    (max   24508)
http://safemode.homeip.net/so-swap.png   (max   118132)
http://safemode.homeip.net/bi-swap.png    (max   24536)	

finally, i redid the swap one i have posted before.  This time it has correct 
scaling.  Because of this you'll see a final dropoff of the aa's graph to 0, 
disregard it,  as well as all of the 0 data in the other graphs as they're 
there to keep scale correct.  Everything after 52 seconds in the aa graphs is 
filler.  

http://safemode.homeip.net/swap.png    (max   290740)

All of these are larger than before due to the larger dimensions of the graph 
files.  feel free to mirror them if i end up not being fast enough. 




On Wednesday 31 October 2001 22:18, safemode wrote:
> In an earlier post i mentioned a way of locking up my vm easily and
> repeatedly but that has since been fixed in one way or another.  I reran
> the test and took vmstat 1 's of both runnings on a 2.4.14-pre6-preempt
> kernel and a 2.4.13-ac5-preempt kernel.  I began both vmstat's at the same
> time (about 4 seconds before running each).  What i did was run kghostview
> on a postscript file located here http://safemode.homeip.net/test.ps  .  It
> is 224K.  kmail was loaded previously in both trials so kdeinit was already
> loaded as were all libs.   After kghostview became responsive, i waited a
> few seconds (again about 5) and then exited the app.
>
> No other interaction or running programs were present while doing this.
> I have 771580 KB of ram and 290740 KB of swap.
>
> Now to explain the graphs.
> The blue is AA's vm.  The red is Rik's vm.  Rik's vm finished in 66
> seconds. AA's vm finished in 52 seconds.  Both start at 0 swap usage.  Both
> from clean boots.
>
> Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   .
> It's about 4.6K.
>
> When you look at the graph it goes like this.
> The left side is 0 seconds, the right side is 66 seconds.  bottom is 0KB,
> top is 290740KB.
>
> These are generated from data from the orignal vmstat outputs.  These are
> at http://safemode.homeip.net/aa_vmstat
> and
> http://safemode.homeip.net/rik_vmstat
>
> I'll leave the actual interpretation of the data of both the graph and raw
> data up to those who actually know the code.
>
> Neadless to say that while running the test on either box, the entire
> computer became unresponsive multiple times for extended lengths of times.
> No OOM was generated on either run.

Re: graphical swap comparison of aa and rik vm

[Mark Hahn]

> Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   . It's 

here's my munge of the same data:
	http://mhahn.mcmaster.ca/~hahn/foo.png
the measures I find interesting are the SI/SO rates.  first, the most obvious
feature is that Rik-VM has a serious problem knowing when to *stop* swapping
out.  but SO isn't a bad thing unless it's obsessive: it's when you see high 
*swap-in* that you know the VM has previously chosen bad pages to SO.  
and this is the second big difference: Rik-VM doesn't make nearly as many
mistakes - especially look at Andrea-VM thrashing out-in-out at ~ samples 26-32.

also, if you merely sum the SI and SO columns for each:
		sum(SI)		sum(SO)		sum(SI+SO)
      Rik-VM	43564		317448		290032
      AA-VM	118284		171748		361012
to me, this looks like the same point: Rik being SO-happy, 
Andrea having to SI a lot more.  interesting also that Andrea wins the race, 
in spite of poorer SO choices and more swap traffic overall.

> Neadless to say that while running the test on either box, the entire 
> computer became unresponsive multiple times for extended lengths of times.  

yes, unfortunately this corrupts the value of the data, since the timecourses
are not really comparable, and samples are only vaguely related to time...

regards, mark hahn.

Re: graphical swap comparison of aa and rik vm

[safemode]

On Thursday 01 November 2001 01:23, Mark Hahn wrote:
> > Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   .
> > It's
>
> here's my munge of the same data:
> 	http://mhahn.mcmaster.ca/~hahn/foo.png
> the measures I find interesting are the SI/SO rates.  first, the most
> obvious feature is that Rik-VM has a serious problem knowing when to *stop*
> swapping out.  but SO isn't a bad thing unless it's obsessive: it's when
> you see high *swap-in* that you know the VM has previously chosen bad pages
> to SO. and this is the second big difference: Rik-VM doesn't make nearly as
> many mistakes - especially look at Andrea-VM thrashing out-in-out at ~
> samples 26-32.
>
> also, if you merely sum the SI and SO columns for each:
> 		sum(SI)		sum(SO)		sum(SI+SO)
>       Rik-VM	43564		317448		290032
>       AA-VM	118284		171748		361012
> to me, this looks like the same point: Rik being SO-happy,
> Andrea having to SI a lot more.  interesting also that Andrea wins the
> race, in spite of poorer SO choices and more swap traffic overall.
>
> > Neadless to say that while running the test on either box, the entire
> > computer became unresponsive multiple times for extended lengths of
> > times.
>
> yes, unfortunately this corrupts the value of the data, since the
> timecourses are not really comparable, and samples are only vaguely related
> to time...

If you miss anything you miss the plateu data that would be found  when the 
IO peaks.  But i doubt much at all was really lost in this case.  
> regards, mark hahn.

Actually i found that most if not all of the vmstat's that weren't being 
displayed were displayed immediately after the "locks", ie. I got flooded 
with vmstats upon the computer becoming responsive again.   
Of course I should have been timing each run with a stopwatch, but that never 
crossed my mind that the vmstat would be lost.   In other words i thought of 
it as analogous to having burst-lag on irc.  Guess that's for tomorrow after 
work.  

Re: graphical swap comparison of aa and rik vm

[safemode]

On Thursday 01 November 2001 01:23, Mark Hahn wrote:
> > Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   .
> > It's
>
> here's my munge of the same data:
> 	http://mhahn.mcmaster.ca/~hahn/foo.png
> the measures I find interesting are the SI/SO rates.  first, the most
> obvious feature is that Rik-VM has a serious problem knowing when to *stop*
> swapping out.  but SO isn't a bad thing unless it's obsessive: it's when
> you see high *swap-in* that you know the VM has previously chosen bad pages
> to SO. and this is the second big difference: Rik-VM doesn't make nearly as
> many mistakes - especially look at Andrea-VM thrashing out-in-out at ~
> samples 26-32.
>
> also, if you merely sum the SI and SO columns for each:
> 		sum(SI)		sum(SO)		sum(SI+SO)
>       Rik-VM	43564		317448		290032
>       AA-VM	118284		171748		361012
> to me, this looks like the same point: Rik being SO-happy,
> Andrea having to SI a lot more.  interesting also that Andrea wins the
> race, in spite of poorer SO choices and more swap traffic overall.

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.  

Re: graphical swap comparison of aa and rik vm

[Helge Hafting]

Mark Hahn wrote:
> 
> > Here is the graph   http://safemode.homeip.net/vm_swapcomparison.png   . It's
> 
> here's my munge of the same data:
>         http://mhahn.mcmaster.ca/~hahn/foo.png
> the measures I find interesting are the SI/SO rates.  first, the most obvious
> feature is that Rik-VM has a serious problem knowing when to *stop* swapping
> out.  but SO isn't a bad thing unless it's obsessive: it's when you see high
> *swap-in* that you know the VM has previously chosen bad pages to SO.

Sure.  SO isn't bad for the benchmark, but think of the guy trying 
to use the machine after the test finished.  It probably swapped out
a lot of other processes which is why you didn't see it swap in again.
These things weren't needed for the bench, but daily use don't
look like that.  If my big job takes a long time - no problem
if I can work on something else with nice performance.

> and this is the second big difference: Rik-VM doesn't make nearly as many
> mistakes - especially look at Andrea-VM thrashing out-in-out at ~ samples 26-32.
> 
> also, if you merely sum the SI and SO columns for each:
>                 sum(SI)         sum(SO)         sum(SI+SO)
>       Rik-VM    43564           317448          290032
>       AA-VM     118284          171748          361012
> to me, this looks like the same point: Rik being SO-happy,
> Andrea having to SI a lot more.  interesting also that Andrea wins the race,
> in spite of poorer SO choices and more swap traffic overall.

It'd be real interesting to know wether or not the "excessive" swapping 
caused extra seeks. Readahead or simply reading more consecutive blocks 
don't hurt - while seeks do.  Perhaps this is why it didn't hurt so
much?

Also consider the multiuser aspect - punishing a memory pig with
extra swapin isn't necessarily so bad, if it keeps more memory around
for others.  Could possibly be bad for a dedicated box, but Andrea won 
on speed anyway.

Helge Hafting

Re: graphical swap comparison of aa and rik vm

[Rik van Riel]

On Thu, 1 Nov 2001, Mark Hahn wrote:

> also, if you merely sum the SI and SO columns for each:
> 		sum(SI)		sum(SO)		sum(SI+SO)
>       Rik-VM	43564		317448		290032
>       AA-VM	118284		171748		361012
> to me, this looks like the same point: Rik being SO-happy,
> Andrea having to SI a lot more.  interesting also that Andrea wins the race,
> in spite of poorer SO choices and more swap traffic overall.

I think this is because in safemode's test, the swap space
gets exhausted.  My VM works better when there is lots of
swap space available but degrades in the (rare) case where
swap space is exhausted.

Testing corner cases always gives interesting results ;)

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: graphical swap comparison of aa and rik vm

[safemode]

On Thursday 01 November 2001 07:10, Rik van Riel wrote:
> On Thu, 1 Nov 2001, Mark Hahn wrote:
> > also, if you merely sum the SI and SO columns for each:
> > 		sum(SI)		sum(SO)		sum(SI+SO)
> >       Rik-VM	43564		317448		290032
> >       AA-VM	118284		171748		361012
> > to me, this looks like the same point: Rik being SO-happy,
> > Andrea having to SI a lot more.  interesting also that Andrea wins the
> > race, in spite of poorer SO choices and more swap traffic overall.
>
> I think this is because in safemode's test, the swap space
> gets exhausted.  My VM works better when there is lots of
> swap space available but degrades in the (rare) case where
> swap space is exhausted.
>
> Testing corner cases always gives interesting results ;)
>
> regards,
>
> Rik

In my previous post i mentioned something like that as to why your vm didn't 
perform as well.  The thing isn't that you use all of my available memory 
(ram + swap), it's that you allocate it all, leaving nothing for the program 
later on.  I think anything that uses almost a gig of ram outside of 
databases is going to be a corner case, but perhaps a better way to figure 
out how much memory should be allocated is needed here.   Andrea's vm seems 
to do a good job at that.  if only he could figure out a better way to swap 
out pages correctly the first time (as some people say his made more mistakes 
than yours) then i cant really find anything bad about it.  And i'm trying 
to.  

Also as others pointed out.   After the process was done. You had quite a lot 
more swap still allocated.  Why exacty?   

Re: graphical swap comparison of aa and rik vm

[Dirk Moerenhout]

> also, if you merely sum the SI and SO columns for each:
> 		sum(SI)		sum(SO)		sum(SI+SO)
>       Rik-VM	43564		317448		290032
>       AA-VM	118284		171748		361012
> to me, this looks like the same point: Rik being SO-happy,
> Andrea having to SI a lot more.  interesting also that Andrea wins the race,
> in spite of poorer SO choices and more swap traffic overall.

Just cause I didn't see anybody mentioned it yet: your statement is not
valid you switched the SI+SO values. It's 361012 for Rik-VM and 290032 for
AA-VM (easy to see as SO for Rik-VM is higher than the sum for Rik-VM in
your table ;-) ). So AA makes less swap traffic overall which does
actually explain at least partially why it wins the race.

Regards,

Dirk Moerenhout ///// System Administrator ///// Planet Internet NV

Re: graphical swap comparison of aa and rik vm

[safemode]

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.  

Re: graphical swap comparison of aa and rik vm

[Rik van Riel]

On Thu, 1 Nov 2001, safemode wrote:

> 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.

Note that this is likely to be a side effect of running
completely out of swap, because that means many of the
"obvious candidates" of what to swap out cannot be swapped
out, meaning we have to scan more pages until we find
something which already has swap backing.

Before you draw conclusions like the one above, please test
again with more swap.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: graphical swap comparison of aa and rik vm

[safemode]

On Friday 02 November 2001 06:17, Rik van Riel wrote:
> On Thu, 1 Nov 2001, safemode wrote:
> > 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.
>
> Note that this is likely to be a side effect of running
> completely out of swap, because that means many of the
> "obvious candidates" of what to swap out cannot be swapped
> out, meaning we have to scan more pages until we find
> something which already has swap backing.
>
> Before you draw conclusions like the one above, please test
> again with more swap.
>
> regards,
>
> Rik

I'll try it with  more swap later on today after work.  But realize, though,  
the fact that you need much more swap to do the same thing (compared to aa's) 
is not helping any adoption of the VM.  

Re: graphical swap comparison of aa and rik vm

[Rik van Riel]

On Fri, 2 Nov 2001, safemode wrote:

> I'll try it with more swap later on today after work.  But realize,
> though, the fact that you need much more swap to do the same thing
> (compared to aa's)  is not helping any adoption of the VM.

Uhhh ... this is nothing but a classical speed/size tradeoff.

The fact that under my VM swap space stays reserved for the
program on swapin means that if the page isn't dirtied, we
can just drop it without having to write it to disk again.

In situations where there is enough swap available, this
should be a win (and it has traditionally been a big win).

Andrea's VM always frees swap space on swapin, so even if
the process doesn't write to its memory at all, the data
still needs to be written out to disk again.

Only in the one corner-case where my VM runs out of swap
space and Andrea's VM doesn't yet run out of swap you'll
find situations where the tactic used by Andrea's VM has
its advantages, but I consider this to be a rare situation.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

Re: graphical swap comparison of aa and rik vm

[safemode]

[-- Attachment #1: Type: text/plain, Size: 1311 bytes --]

So I added more swap, for 461549568 bytes total, and guess what happens?  No, 
Rik's vm did not beat AA's.  You might say, "well then it must have came 
close to tying it now since it has enough swap and wont fall victim to the 
'speed/size tradeoff'".  No, you would be wrong.  Rik's VM completely locked 
up in some kind of infinite swap loop like it did before in earlier kernels. 
My server was swapping ( i saw disk activity) for over 8 hours before i 
finally rebooted it.  Needless to say that it angers me to unintentionally 
lock the computer up.  So what's going on here? rik, anyone?  I've used this 
test before to lock up Rik's VM and it is reproduceable on my machine.  With 
less swap, it seems to be gone in the latest kernels but when i added more 
like Rik said to do, it locked up.  For now i'll be running AA kernels until 
this is figured out.  
What i found insane from the little info provided by the vmstat i had running 
at the time was that even with 450+MB of swap, Rik's VM still used it all up. 
Why would it work better without that much ram but when i add more, it still 
uses it all up and locks up.  There's something seriously wrong here. I'm 
going to test's andrea's with the new mem config too later.   My bet is that 
it doesn't lock up for over 8 hours trying to swap. 
  

[-- Attachment #2: stats --]
[-- Type: text/plain, Size: 5492 bytes --]

   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 0  0  0      0 293672   1612 353488   3   7    22    12  133     5   6   0  94
 1  0  0      0 293672   1612 353488   0   0     0     0  206   599   2   2  96
 0  0  0      0 293672   1612 353488   0   0     0     0  147   350   1   0  99
 1  0  0      0 292488   1648 354056   0   0   640     0  146   238  12   1  87
 0  1  0      0 291364   1772 354452   0   0   644     0  177   450  28   1  71
 0  1  0      0 289344   1848 355792   0   0  1492     0  204   614  19   3  78
 1  0  0      0 245996   1876 356080   0   0   344     0  142   361  71   7  22
 1  0  0      0 176396   1876 356080   0   0     0     0  103   149  85  15   0
 1  0  0      0  44644   1876 356080   0   0     0     0  105   131  82  18   0
 1  0  1  23692   3060   1816 323856   0   0     8     0  105   125  46  54   0
 1  0  0  90888   3064   1816 222196   0   0     0     0  107   132  67  33   0
 1  0  0  90888   3064   1816  92024   0   0     0     0  103   130  70  30   0
 1  1  0 364144   3800    500  10284   0 74548    32 74876  209   285  49  46   5
 1  2  1 364132   3056    500   9760   0 27656     0 27652  230    81   4  45  51
 0  3  1 364132   3056    500   9760   0 17864     0 17868  243   135   0   1  99
 1  4  2 364120   3060    516   9736   0 27384    16 27372  408    64   1  35  64
 3  1  0 364220   4608    524   9720   0 10356     8 10372  377    35   2  96   3
 0  4  0 364216   3064    524   9548  64   0    68     4  261    28  45  32  24
 0  6  0 364216   3064    524   9556  64   0    72     0  250    31   0   2  98
 0  8  0 364192   3064    528   9556 120   0   124     0  246    34   0   1  99
 0  9  0 364192   3064    528   9616  64   0   128     0  247    32   0   1  99
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 0  8  0 363868   3064    556  10868 1568   0  2880     0  220   162   0   0 100
 0  6  0 362480   3064    604  11956 2948   0  4132     0  221   278   1   5  94
 1  1  0 361664   3064    636  12740 2172   0  3020     0  218   263   3   1  96
 2  0  0 360584   3064    676  13512 2704   0  3556     0  254   363  16   3  81
 1  2  0 360584   3064    736  14684 704   0  1996     0  244   299  52   6  42
 0  2  0 360584   3064    764  15552 1856   0  2780     0  187   269   2   1  97
 0  2  0 360584   3064    820  16980 564   0  2104     0  216   305  55   7  38
 1  1  0 360584   3064    824  17276 2048   0  2352     0  176   262   9   4  87
 1  0  0 360584   3064    864  17524 5632   0  5960     0  227   366   7   4  89
 1  0  1 371040   3060    864  17524 15000   0 15000     8  348   604  31  28  42
 1  0  0 360584   3064    864  17532 7764 5536  7772  5536  276   365  38  33  30
 2  0  0 360584   3064    864  17532   0   0     0     0  105   134 100   0   0
 1  0  0 360584   3064    880  17564 480   0   544     0  128   166  99   1   0
 0  2  0 360584   3064    900  16388 3740   0  4140     0  233   557  12   0  88
 2  0  0 360584   3064    872  16224 5236   0  5448     0  276   491   7  14  79
 2  1  1 380092   3064    960  15768 360 10376   708 10596  662   203  67  33   0
 1  0  1 450728   3488    960  15772  56 5536    60  5540  109   126  50  50   0
 1  0  0 374020   3360    964  15896   0   0   132     0  162   207  68  10  22
 1  0  0 360584   3360    964  15896   0   0     0     0  105   129  77  23   0
 1  2  0 360584   3060    968  16472 120   0   704     0  135   162  99   1   0
 1  0  0 360584   3064   1020  16824 588   0  1048     0  195   260  87  13   0
   procs                      memory    swap          io     system         cpu
 r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us  sy  id
 1  0  0 360584   3064   1044  16824 128   0   176     8  134   173  99   1   0
 1  0  0 360584   3064   1044  16824   0   0     0     0  115   144 100   0   0
 1  0  0 360584   3064   1048  16828   0   0    12     0  129   154 100   0   0
 1  2  1 360584   3060    572   7092 1188 2756  1436  2904  401 13212  45  34  22
 2  2  1 361932   3060    616   5520  12 11012   120 11008  372   288   2  48  50
 6  0  2 361564   3060    644   5372 236 34696   308 34696  346   130   3  70  27
 3  2  2 450716   3064    664   4164 108 2620   264  2636  285   138  21  72   8
15  0  1 450696   3072    764   3920 180 123424   308 123420 1996  1144   0  21  78
 4  3  1 450732   3064    868   5024 1304 25220  2616 25268  333   233  45  55   0
11  3  2 450728   2760    912   4984 224 53036   272 53024 1297   234   1  44  54
 7  2  1 450732   2824    940   5792 800 89672  1744 89744 1336   311   6  47  47
 1  4  0 450732   3492    496   3376 184  52   192    52  246    39  38  62   0
 1  4  0 450716   3064    428   3256 168 3688   652  3684  327    82  14  71  16
 2  1  0 450728   3064    492   4088 392 14196  1476 14200  464   222   3  50  47
 6  0  0 450732   3552    524   4056 108 8448   152  8468  381   138   4  56  40
 1  5  1 450728   3060    472   3064 844 9596  1308  9616  371   276   7  93   0
 3  1  1 450728   3060    436   2864 796 172  1224   212  279   688   2  98   0
 4  1  1 450728   3060    288   2892 1036 116  2140   192  471  2643   0 100   0
 6  1  1 450728   3060    312   2912 1160  96  3364   132  609  2683   0 100   0
 9  0  1 450732   3060    304   2776 1132 112  2876   144  434  1242   0 100   0

Re: graphical swap comparison of aa and rik vm

[safemode]

Since i'm now in Linus' kernel, i did the test again on it with the added 
swap.  It took about 7 minutes to finish.  Since rik's vm locked up so 
completly after only about a minute, i really have no data on what it was 
doing during those 8 hours i had it running it's course.  Andrea's was more 
fruitful and vmstat ran quite nicely the entire time, probably only missing a 
couple here and there.  
The only thing i could tell from the two tests is that Rik's vm allocates all 
of my memory and swap almost immediately and for extended periods of time.  
Andrea's alocates memory gradually and more conservatively and only reaches 
all of my swap for an instant.  Other than that the only thing i can tell is 
that my computer is usable when using andrea's vm after the test.  I have to 
reboot it after starting the test with Rik's vm. 




On Friday 02 November 2001 18:48, safemode wrote:
> So I added more swap, for 461549568 bytes total, and guess what happens? 
> No, Rik's vm did not beat AA's.  You might say, "well then it must have
> came close to tying it now since it has enough swap and wont fall victim to
> the 'speed/size tradeoff'".  No, you would be wrong.  Rik's VM completely
> locked up in some kind of infinite swap loop like it did before in earlier
> kernels. My server was swapping ( i saw disk activity) for over 8 hours
> before i finally rebooted it.  Needless to say that it angers me to
> unintentionally lock the computer up.  So what's going on here? rik,
> anyone?  I've used this test before to lock up Rik's VM and it is
> reproduceable on my machine.  With less swap, it seems to be gone in the
> latest kernels but when i added more like Rik said to do, it locked up. 
> For now i'll be running AA kernels until this is figured out.
> What i found insane from the little info provided by the vmstat i had
> running at the time was that even with 450+MB of swap, Rik's VM still used
> it all up. Why would it work better without that much ram but when i add
> more, it still uses it all up and locks up.  There's something seriously
> wrong here. I'm going to test's andrea's with the new mem config too later.
>   My bet is that it doesn't lock up for over 8 hours trying to swap.