Re: why swap at all?

[Bill Davidsen]

Con Kolivas wrote:
> On Wed, 2 Jun 2004 15:38, FabF wrote:
>
> > On Wed, 2004-06-02 at 01:17, Bernd Eckenfels wrote:
> >
> > > In article <200406012000.i51K0vor019011@xxxxxxxxxxxxxxxxxxxxxxx> you 
>
> wrote:
>
> > > > out (unlike some, I don't mind if Mozilla or OpenOffice end up out on
> > > > disk after extended inactivity - but if my window manager gets swapped
> > > > out, I get peeved when focus-follows-mouse doesn't and my typing goes
> > > > into the wrong window or some such... ;)
> > >
> > > Yes but: your wm is so  often used/activated it will not get swaped  out.
> > > But if your mouse passes over mozilla and tries to focus it, then you
> > > will feel the pain of a swapped-out x program.
> >
> > Exactly !
> > Does autoregulated VM swap. patch could help here ?
>
>
> Unless you are pushing the limits of your available ram by your usage pattern 
> then yes the autoregulated swappiness patch should help.
>
> available here:
> http://ck.kolivas.org/patches/2.6/2.6.7-rc2/patch-2.6.7-rc2-am11
>
> Just a brief word that might clarify things for people. It seems this huge 
> swap discussion centres around 2 different arguments. Akpm has said that the 
> correct way for the vm to behave is that of swappiness=100. Desktop users 
> note they have less swap out of the programs they use with swappiness 0 or 
> their swap turned off. When your swappiness is set high, the current vm 
> decisions are the fastest they can be, but when you go back to your 
> applications they will take longer to restart. When your swappiness is set 
> low your applications will restart rapidly, but the current vm will be doing 
> more work and be slower. Most benchmarks will show the latter, but most 
> desktop users will feel the former and not really notice the latter.
>
> Try the little experiment to see: Boot with mem=128M and try to compile a 2.6 
> kernel with all the debugging symbols option enabled - do this with 
> swappiness set to 0 and then at 100. You'll see it compile much faster at 
> 100. Yet you know that if you set your swappiness to 0 mozilla will load 
> faster next time you use it on your desktop during your normal usage pattern 
> (of course you'd probably be using mozilla on a system with a bit more than 
> 128M ram but this helps demonstrate the point). 
>
> Does this explain in coarse examples to the desktop users why ideal systems 
> shouldn't be swap disabled or swappiness=0 ?
>
> The autoregulated swappiness patch tries to get some sort of common ground, 
> where it sacrifices performance slightly currently to improve what happens 
> the next time you use your machine substantially. Because it changes with the 
> amount of application pages in ram, it will not increasingly sacrifice 
> performance when your memory is full with application pages. What it will not 
> do is improve the swap thrash situation when you have grossly overloaded your 
> ram.

But swap behaviour kills performance even when memory is more than 
adequate. Consider building a DVD image in a 4GB system. The i/o forces 
all of the unused programs out, in spite of the fact that an extra 100MB 
doesn't make a measurable difference in performance. But when I click 
Mozilla paging most of it in from disk make a big difference in 
performance to the user.

My perception is that the system is really bad at recognizing 
diminishing returns to be had by paging programs for the benefit of i/o. 
Not to mention what happens if you get 2-3GB of dirty buffers and then 
do a sync(). In practice my little RAID array will take at most 40MB/s, 
so the creation of a DVD runs fast, but the system bogs right after.

The problems with small memory are different in kind, when not even the 
programs will fit in memory at the same time, or will leave next to 
nothing for i/o, swap is required for performance. But on a large memory 
system I believe the gain to pain ratio is way too low with the current 
VM. The solution at the moment is to turn off swap, which as you note 
has other problems (can't move between zones without swap?) which in 
theory could really hang a system.

--
   -bill davidsen (davidsen@xxxxxxx)
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/