Trying for days now to control the swapping behaviour of the Linux kernel, but no success yet. I set /proc/sys/vm/swappiness. to 0, 1, 60, 85 and 100 and started a small c-program which eats up all the memory. Free shows the same situation in all cases: though there is plenty of free mem, the cache is encreased immediately. And as soon as no free memory is left the actual swapping starts after a short freeze.

I expected that if swappiness is set to 0 no caching at all is used.
I tried this on a desktop system with a plain 2.6.23.8 kernel as well as with a 2.6.19 Gentoo genkernel. What I would like to see is no caching at all and no swapping as long as the free memory isn't running short.

Anyone knows more about this?
Thx.

Uhh, nope. The swappiness value just controls how aggressive the kernel is in swapping out process memory.
http://lwn.net/Articles/83588/

Is there a particular reason you want caching/swap switched off?

Dave

Thanks for your immediate answer.
My idea was that if caching is switched off the performance would be better. And I hoped also that the short
freeze at the moment when swapping starts would disappear. I want to understand the impact of
the swappiness parameter because it is described everywhere. But by monitoring "watch 'free'" with different values
for swappiness I couldn't see any difference.
Norbert

Max-ing out the memory probably isn't a valid test. Depends on how you are allocating and referencing the memory though.
Given that you are on recent kernel versions, try flushing the caches first;
"echo 3 > /proc/sys/vm/drop_caches"

With caching switched off, performance would be /significantly/ worse - every file read / write would have to go to disk, instead of hitting the RAM cache.

ok, I made another test:

Plain 2.6.23.8 kernel from kernel.org:

echo 0 > /proc/sys/vm/swappiness
echo 3 > /proc/sys/vm/drop_caches

Now I start to allocate more and more memory.
This is done by a c-program which allocates memory for lots of empty
character arrays with malloc().

As expected the used cache is increasing while the free memory is decreasing.
Then the swapping starts, freeze and the used swap jumps from 0 to 98744.

reboot
echo 100 > /proc/sys/vm/swappiness
echo 3 > /proc/sys/vm/drop_caches

Again allocating memory. There is the same behavior with free mem and cache.
But when the swapping starts the used swap jumps from 0 to 150700.


I made several tests and this is what happened each time. So the only difference is the amount
of used swap in the beginning of the swapping. As soon as swapping has started
the behavior in both scenarios looks the same to me. The used cache is almost full and it remains
full in both cases, the used swap increases.
No changes to the used cache wether swappiness is 0 or 100. Hm, here I expected a reduce of the
used cache if swappiness is low.
But as you mentioned before there may be more valid test scenarios for this.

Hi again.

The behaviour you're seeing looks to me to be reasonable.

The kernel uses some metrics to decide what, and when to swap, so I'd imagine a process which is doing malloc() but never actually touching the memory allocated would be a prime candidate for swapping out. Perhaps when it becomes time to start swapping, the kernel swaps it out more aggressively (i.e. swaps out more) with a higher swappiness value than with a lower swappiness.

There may also be some weirdness associated with overcommit (I'm assuming you're not actually filling the malloc()ed memory with data here), but I don't know how that affects the swap behaviour.

Can you modify the program to do a bunch of fork()s and allocate memory from each thread, and see what happens when it's not just one thread malloc()ing? Or maybe actually fill the malloc()ed memory with data as it's allocated, and see if that affects things?

Usual disclaimer, I'm not a kernel developer, so I may be talking out of my ass.

Dave

Hi Dave

yesterday I tested it with forking and filling the memory with data.
The difference is now very obvious. With swappiness=0 the
used swap jumps from 0 to 126516, with swappiness=100 it jumps to 255600.
The caching is propably something which needs much more research to fully understand its behaviour.
Anyway thanks very much for your support!