lkml.org 
[lkml]   [2004]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Autotune swappiness01
Date
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@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.059 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site