[lkml]   [2011]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH -v2 -mm] add extra free kbytes tunable
On Wed, 12 Oct 2011, Satoru Moriya wrote:

> >> Also, if we increase the free-page reserves a.k.a min_free_kbytes,
> >> the possibility of direct reclaim on other workloads increases.
> >> I think it's a bad side effect.
> >
> > extra_free_kbytes has the same side-effect.
> I don't think so. If we make low watermark bigger to increase
> free-page reserves by extra_free_kbytes, the possibility of
> direct reclaim on other workload does not increase directly
> because min watermark is not changed.

I think the point was that extra_free_kbytes needs to be tuned to cover at
least the amount of memory of the largest allocation burst or it doesn't
help to prevent latencies for rt threads and, depending on how the
implementation of the VM evolves, that value may change significantly over
time from kernel release to kernel release.

For example, if we were to merge Con's patch so kswapd operates at a much
higher priority for rt threads later on for another issue, it may
significantly reduce the need for extra_free_kbytes to be set as high as
it is. Everybody who is setting this in init scripts, though, will
continue to set the value because they have no reason to believe it should
be changed. Then, we have users who start to use the tunable after Con's
patch has been merged and now we have widely different settings for the
same tunable and it can never be obsoleted because everybody is using it
but for different historic reasons.

This is why I nack'd the patch originally: it will never be removed, it
is widely misunderstood, and is tied directly to the implementation of
reclaim which will change over time.

 \ /
  Last update: 2011-10-13 00:45    [W:0.068 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site