[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 10/12/2011 06:41 PM, David Rientjes wrote:
> On Wed, 12 Oct 2011, Satoru Moriya wrote:
> 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

Right. In enterprise area, we strictly test the system we build
again and again before we release it. In that situation, we can
set extra_free_kbytes appropriately based on system's requirements
and/or specifications etc.

> or it doesn't help to prevent latencies for rt threads and,

I thinks it also helps rt threads prevent latency as well as
normal threads because we can start kswapd earlier and avoid
direct reclaim.

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

I understand what you concern. But in some area such as banking,
stock exchange, train/power/plant control sysemts etc this kind
of tunable is welcomed because they can tune their systems at
their own risk.

Also those systems have been used for a long time without significant
updating. If we update it or build a new system, we configure all
tunables from scratch.


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