lkml.org 
[lkml]   [2004]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Autoregulate swappiness & inactivation
Date
Andrew Morton writes:

> 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 :)

/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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.062 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site