Re: swapping and the value of /proc/sys/vm/swappiness

Con Kolivas
2004-09-14T22:59:31Z

Marcelo Tosatti wrote:
> On Tue, Sep 14, 2004 at 11:31:53AM -0700, Florin Andrei wrote:
>
>>On Mon, 2004-09-06 at 16:27, Andrew Morton wrote:
>>
>>>Con Kolivas <kernel@kolivas.org> wrote:
>>
>>>> The change was not deliberate but there have been some other people report
>>>> significant changes in the swappiness behaviour as well (see archives). It
>>>> has usually been of the increased swapping variety lately. It has been
>>>> annoying enough to the bleeding edge desktop users for a swag of out-of-tree
>>>> hacks to start appearing (like mine).
>>>
>>>All of which is largely wasted effort.
>>
>>>From a highly-theoretical, ivory-tower perspective, maybe; i am not the
>>one to pass judgement.
>>>From a realistic, "fix it 'cause it's performing worse than MSDOS
>>without a disk cache" perspective, definitely not true.
>>
>>I've found a situation where the vanilla kernel has a behaviour that
>>makes no sense:
>>
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109237941331221&w=2
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109237959719868&w=2
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109238126314192&w=2
>>
>>A patch by Con Kolivas fixed it:
>>
>>http://marc.theaimsgroup.com/?l=linux-kernel&m=109410526607990&w=2
>>
>>I cannot offer more details, i have no time for experiments, i just need
>>a system that works. The vanilla kernel does not.
>
>
> Have you tried to decrease the value of /proc/sys/vm/swappiness
> to say 30 and see what you get?
>
> Andrew's point is that we should identify the problem - Con's patch
> rewrites swapping policy.

I already answered this. That hard swappiness patch does not really
rewrite swapping policy. It identifies exactly what has changed because
it does not count "distress in the swap tendency". Therefore if the
swappiness value is the same, the mapped ratio is the same (in the
workload) yet the vm is swappinig more, it is getting into more
"distress". The mapped ratio is the same but the "distress" is for some
reason much higher in later kernels, meaning the priority of our
scanning is getting more and more intense. This should help direct your
searches.

These are the relevant lines of code _from mainline_:

distress = 100 >> zone->prev_priority
mapped_ratio = (sc->nr_mapped * 100) / total_memory;
swap_tendency = mapped_ratio / 2 + distress + vm_swappiness
if (swap_tendency >= 100)
- reclaim_mapped = 1;

That hard swappiness patch effectively made "distress == 0" always.

Con