disabling kswapd
Sasha Pachev
My original message for some reason did not seem to make it to the list, so I
am resending this (with some modifications).
I have noticed that kswapd still runs and in when the memory is low, will do
some hard thinking about what to swap even if the system does not have a swap
partition. Here is the proof:
sasha@mysql:/usr/src/linux/mm > free
total used free shared buffers cached
Mem: 254816 248476 6340 0 27224 48832
-/+ buffers/cache: 172420 82396
Swap: 0 0 0
sasha@mysql:/usr/src/linux/mm > ps auxw | grep kswapd
root 5 0.1 0.0 0 0 ? SW Dec19 1:41 [kswapd]
sasha 25619 0.0 0.2 1552 612 pts/7 S 20:34 0:00 grep kswapd
So in this example kswapd essentially wasted 1 min and 41 sec of CPU time.
I have search through the archive and discovered a patch to disable kswapd
through proc at
http://www.uwsg.iu.edu/hypermail/linux/kernel/0108.0/0675.html. I adapted it
to my kernel ( 2.4.17-rc2), disabled kswapd, did some testing and noticed
much better performance.
I would like to request that the above patch in some form be officially
included in the kernel. While a *perfectly working* kswapd on a system with
many different processes behaving in a somewhat unpredicatable manner will be
a boon, there are many instances when running kswapd does more harm than
good. Below are three reasons why a sysadmin may want to have kswapd disabled:
* the system is configured in such a way that it has plenty of RAM for
buffers,cache, and all the processes it will ever run. For example, a
dedicated server machine with lots of RAM, a small server binary, and a set
of files it reads that alltogether will fit into RAM - many MySQL
installations fit into this category. Running kswapd in this case would only
be a waste of CPU
* kswapd has a nasty bug that hogs CPU, causes kernel panic, or swaps out so
aggressively that the system becomes unusable.
* some other code in the kernel does not work well with kswapd - the
particular problem I've run into, for example, was kswapd going crazy trying
to shrink the buffers while find / was causing the kernel to expand them. The
result was kswapd taking up 75% of CPU.
The bottom line is that a sysadmin should have a choice ( isn't that what
Linux is all about, after all?). If he does not want to run kswapd, he should
not have to. If he is really wrong in this, let him find out for himself.
--
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sasha Pachev <sa...@mysql.com>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, http://www.mysql.com/
/_/ /_/\_, /___/\___\_\___/ Provo, Utah, USA
<___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Sasha Pachev
> On Fri, 21 Dec 2001, Sasha Pachev wrote:
>
> > http://www.uwsg.iu.edu/hypermail/linux/kernel/0108.0/0675.html. I
> > adapted it to my kernel ( 2.4.17-rc2), disabled kswapd, did some
> > testing and noticed much better performance.
>
>
> If kswapd does not run, it just means that _other_ processes
> will run the exact same code, only synchronously (instead of
> having kswapd do the cleanup for them).
That does make a difference. kswapd does its clean-up in a loop that runs
with very high priority every time it thinks that there are not enough free
pages. The process will only run this code if it actually fails to find a
free page, and if I understand correctly, do so with its regular priority,
right?
In my case, I do not mind if the process gets stuck looking for a free page
while letting other processes that already have all the pages they need run,
as opposed to kswapd monopolizing the CPU trying to clean up.
So, I would like to reiterate that kswapd disabling feature would be very
helpful to have in the kernel. It involves only trivial code changes, and it
does allow a sysadmin to do things a different way - like I said earlier,
Linux is about choice, and when it is possible, one should have it.
But actually, digging a little deeper - I think there is still a bug in
shrink_caches(). Even after disabling kswapd, in one instance I had a process
brutally murdered at the time when I had over 100MB of cache available. The
cache was heavily used and growing, if that helps any.
It must be noted that the one process murder in this case did not compare
with a massacre that happened in the same situation when kswapd was not
disabled. About 10 processes got killed.