Re: Autoregulate swappiness & inactivation

[Nick Piggin]

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.

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