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

[Con Kolivas]

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@xxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/