Re: Autoregulate swappiness & inactivation

[Nick Piggin <nickpiggin@yahoo.com.au>]

Con Kolivas wrote:
> Nick Piggin writes:
> 

>> OK that's easy then. The OOM algorithm can be changed if it is
>> OOMing too easily.
> 
> 
> I didn't say it was easy, just harder with; but whatever - I can get rid 
> of it.
> 

Please.

>>>> Secondly, can you please not mess with the exported sysctl. If you
>>>> think your "autoswappiness" calculation is better than the current
>>>> swappiness one, just completely replace it. Bonus points if you can
>>>> retain the swappiness knob in some capacity.
>>>
>>>
>>>
>>> I agree and would like them all removed, but people just love to 
>>> leave the knobs in place. While I dont think the knobs should still 
>>> be there either, I'm not reluctant to leave something that innocuous 
>>> if the users want them.
>>>
>>
>> Well, get rid of the auto-tuning thing to start with, and merge
>> it into the swappiness calculation..
>>
>> Regarding all these knobs, the main thing you want to avoid is
>> having loads of them because you can't find acceptable defaults.
>> I think "swappiness" is in the category of a good sysctl: it is
>> simple, meaningful to the admin, works, etc.
>>
>> It has proven somewhat useful in testing ("set it to blah and see
>> if it still happens"). Or for people who know what they are doing.
> 
> 
> Umm I think we're agreeing, no? I'm trying to leave the swappiness knob 
> in for those who (think?) they know what they're doing. Somehow it needs 
> to be turned to "manual" again.
> 

No. Fold your all "autoswappiness" stuff directly into the
reclaim_mapped calculation that was previously keyed off swappiness.
Don't have it modify vm_swappiness at all: work directly on
reclaim_mapped.

Then, you should be able to retain the user's vm_swappiness input
into the system as well. If you can't figure out a good place to
put this in, don't worry about it to start with.