Re: Autoregulate swappiness & inactivation

[Con Kolivas]

Andrew Morton writes:

> Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> > Andrew Morton writes:
> >
> > > Con Kolivas <kernel@xxxxxxxxxxx> wrote:
> > >>
> > >>  Ah what the heck. They can only be knocked back to where they already are.
> > > 
> > > hm.  You get an eGrump for sending two patchs in one email.  Surprisingly
> > > nice numbers though.
> > > 
> > > How come vm_swappiness gets squared?  That's the mysterious "bias
> > > downwards", yes?  What's the theory there?
> >
> > No real world feedback mechanism is linear. As the pressure grows the 
> > positive/negative feedback grows exponentially.
>
> That takes me back.  The classic control system is PID:
> Proportional/Integral/Derivative - they refer to the way in which the error
> term (output-desired output) is fed back to the input:
>
> Proportional: the bigger the error, the more input drive
>
> Integral: feeding back a bit of the integral of the error prevents
> permanent output skew due to non-infinite forward gain.
>
> Derivative: feeding back -(rate of change) provides damping.
>
> You can live without I and D - the main thing is to feed back the -error.
>
> IOW: linear works just fine :)

/me hides

Umm sorry the control systems I look at are physiological and tend to be 
exponential, so ignore me.

> Your answer didn't help me understand the design though.

Ok I'll just describe it. I should have just said that when mapped pages are 
low the best seems to be a very low swappiness, but not zero as zero seems 
to get bogged down easily (kswapd gets busy and basic things take longer) as 
occasionally slipping some pages onto swap helps. Generally it's when what I 
called the application pages (blush) get to around 75% that allowing things 
to swap at the rate equivalent to swappiness==60 is helpful. Once the mapped 
pages went greater than 75% the machine would start bogging down again if 
the swappiness remained at 60. I guess I made up the maths to fill the way 
the design worked best. Linear brought up the swappiness too easily and 
under swap thrash made things worse. It looked nicer but didn't really 
behave well.

> > > Please define this new term "application pages"?
> >
> > errm it's fuzzy to say the least. It's the closest I can come to 
> > representing what end users understand as "non-cached" pages.
>
> Isn't that mapped pages?

I'm all ears.

> > > Those si_swapinfo() and si_meminfo() calls need to come out of there.
> >
> > I'm game. I had the idea but not the skill. Anyone wanna help me with that?
>
> Need to work out what cen be removed first.  The freeswap/totalswap can go.
>  That leaves us needing what?  totalram and freeram.  If the algorithm can
> be flipped over to use nr_mapped, we'd be looking good.

Ok. I need some time to clean up this mess and try and figure out what to do 
then.

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/