Re: Autoregulate swappiness & inactivation

[Andrew Morton <akpm@osdl.org>]

Con Kolivas <kernel@kolivas.org> wrote:
>
> Andrew Morton writes:
> 
> > Con Kolivas <kernel@kolivas.org> 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 :)

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

> > 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?

> > 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.