linux-kernel - RE: [PATCH -v2 -mm] add extra free kbytes tunable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1110121537380.16286@chino.kir.corp.google.com>
Date:	Wed, 12 Oct 2011 15:41:53 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Satoru Moriya <satoru.moriya@....com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Rik van Riel <riel@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Satoru Moriya <smoriya@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"lwoodman@...hat.com" <lwoodman@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	"hughd@...gle.com" <hughd@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>
Subject: RE: [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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/