Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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 18.104.22.168 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.
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.
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"
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.
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.
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!