Hello,
does /proc/sys/vm/swappiness still work as expected?
# /proc/sys/vm# cat swappiness
0
but scp-ing 2GB file causes many processes are swapped out due to increase of
the file cache size. Why? This is totally catastrophic behaviour on the desktop.
Is there a way to avoid it except turning off the swap?
--
Luk?? Hejtm?nek
Hello,
> does /proc/sys/vm/swappiness still work as expected?
> # /proc/sys/vm# cat swappiness
> 0
I think yes. 0 swappiness doesn't mean "no swapping at all". From the
code in shrink_active_list() it seems that it just decreases likeliness
of removing pages of mmaped files (i.e., also executables loaded in memory).
> but scp-ing 2GB file causes many processes are swapped out due to increase of
> the file cache size. Why? This is totally catastrophic behaviour on the desktop.
Yes, that's quite unpleasant. How much memory do you have? If you have
some time, you can try playing with the code in mm/vmscan.c to find out
what's happening in your case (putting some debugging output in
shrink_active_list() etc...
> Is there a way to avoid it except turning off the swap?
Currently, I'm not aware of any way...
Honza
--
Jan Kara <[email protected]>
SuSE CR Labs
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
> Yes, that's quite unpleasant. How much memory do you have? If you have
> some time, you can try playing with the code in mm/vmscan.c to find out
> what's happening in your case (putting some debugging output in
> shrink_active_list() etc...
I think it is a regression in recent rc versions as I use 2.6.24-xx kernels on
my new laptop from the very beginnig I have the laptopt and I did not notice
such behaviour before.
I have 1 GB RAM and I was coping a 2GB file from the network to the laptop.
After the operation, 600MB of the swap area has been consumed. At the
beginning of the copy, the swap area was empty.
--
Luk?? Hejtm?nek
On Mon, 17 Dec 2007 14:17:26 +0100
Lukas Hejtmanek <[email protected]> wrote:
> Hello,
>
> does /proc/sys/vm/swappiness still work as expected?
> # /proc/sys/vm# cat swappiness
> 0
>
> but scp-ing 2GB file causes many processes are swapped out due to increase of
> the file cache size. Why? This is totally catastrophic behaviour on the desktop.
>
Hmm, which version of the kernel do you compare with ?
Seems following patch is the newest one, which changes meaning of swappiness.
Now the swap happens even if swappiness=0, when the system memory usage is highly
unbalanced or when memory reclaim doesn't make progress.
=
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4106f83a9f86afc423557d0d92ebf4b3f36728c1
=
> Is there a way to avoid it except turning off the swap?
>
Maybe...no.
(*) I'm now working on memory resource controller in -mm kernel. please see/try
and comments if interested.
Thanks,
-Kame
On Tue, 18 Dec 2007 10:38:13 +0900
KAMEZAWA Hiroyuki <[email protected]> wrote:
> > Is there a way to avoid it except turning off the swap?
> >
> Maybe...no.
>
Ah, sorry. If too much dirty page by ftp is trouble, tuning
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_writeback/centisecs
etc..
may work for you.
Thanks,
-Kame
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote:
> I think yes. 0 swappiness doesn't mean "no swapping at all". From the
> code in shrink_active_list() it seems that it just decreases likeliness
> of removing pages of mmaped files (i.e., also executables loaded in memory).
So, I tried to add some prints.
I have mapped ratio about 78 while scp-ing the file. Distress suddenly raises
from 0 to 100. At this poing, all the processes are swapped out.
I guess it happens if scp is faster than the local disk which happens if
I scp-ing over GE from desktop (with fast disk - and reading) to laptop (slow
disk - and writing).
This is my settings.
/proc/sys/vm/*
block_dump:0
dirty_background_ratio:10
dirty_expire_centisecs:2999
dirty_ratio:40
dirty_writeback_centisecs:499
drop_caches:0
laptop_mode:0
legacy_va_layout:0
lowmem_reserve_ratio:256 256 32
max_map_count:65536
min_free_kbytes:4006
nr_pdflush_threads:2
oom_kill_allocating_task:0
overcommit_memory:0
overcommit_ratio:50
page-cluster:3
panic_on_oom:0
percpu_pagelist_fraction:0
stat_interval:1
swappiness:0
vfs_cache_pressure:100
--
Luk?? Hejtm?nek