Re: Autotune swappiness01

[Con Kolivas]

Andrew Morton writes:

> > > But decreasing /proc/sys/vm/swappiness does that too?
> >
> > Low memory boxes and ones that are heavily laden with applications find that 
> > ends up making things slow down trying to keep all applications in physical 
> > ram.
>
> Doesn't that mean that swappiness was decreased by too much?

Sure does. But the desired effect when it's not applications is that of 
swappiness being excruciatingly low so people end up doing that. Then they 
find themselves dropping it at nighttime and increasing it during the day.

> > >> It has no measurable effect on any known benchmarks.
> > > 
> > > So how are we to evaluate the desirability of the patch???
> >
> > Get desktop users to report back their experiences which is what I have 
> > currently. Sorry we're in the realm of subjectivity again.
>
> Seriously, we've seen placebo effects before...

I am in full agreement there... It's easy to see that applications do not 
swap out overnight; but i'm having difficulty trying to find a way to 
demonstrate the other part. I guess timing the "linking the kernel with full 
debug" on a low memory box is measurable.

> > > Shouldn't mapped_bias be local to refill_inactive_zone()?
> >
> > That is so a followup patch can use it elsewhere...
>
> erk.  I guess it's OK because the thing is derived from global state which
> changes slowly over time.
>
> > > Why is `swappiness' getting squared?  AFAICT this will simply make the
> > > swappiness control behave nonlinearly, which seems undesirable?
> >
> > To parallel the nonlinear nature of the mapped bias effect. 
>
> That doesn't really answer my question?  What goes wrong if swappiness is
> not squared?

Oh sorry, perhaps I should have said - that keeps people's current settings 
meaningful, but that can happily be broken. That would make the default 
setting something like 34 instead of 60.

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