linux-kernel - RE: [RFC][PATCH 0/2] Tunable watermark

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.1101131421220.26770@chino.kir.corp.google.com>
Date:	Thu, 13 Jan 2011 14:24:50 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Satoru Moriya <satoru.moriya@....com>
cc:	Ying Han <yinghan@...gle.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mel@....ul.ie>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	dle-develop@...ts.sourceforge.net,
	Seiji Aguchi <seiji.aguchi@....com>
Subject: RE: [RFC][PATCH 0/2] Tunable watermark

On Thu, 13 Jan 2011, Satoru Moriya wrote:

> Currently watermark[low,high] are set by following calculation (lowmem case).
> 
> watermark[low]  = watermark[min] * 1.25
> watermark[high] = watermark[min] * 1.5
> 
> So the difference between watermarks are following:
> 
> min <-- min/4 --> low <-- min/4 --> high
> 
> I think the differences, "min/4", are too small in my case.
> Of course I can make them bigger if I set min_free_kbytes to bigger value. 
> But it means kernel keeps more free memory for PF_MEMALLOC case unnecessarily.
> 
> So I suggest changing coefficients(1.25, 1.5). Also it's better
> to make them accessible from user space to tune in response to application
> requirements.
> 

Userspace can't possibly be held responsible for tuning internal VM 
parameters in response to certain workloads like this; if you have 
evidence that different coefficients work better in different 
circumstances, then present the criteria for which you intend to change 
them from the command line via your new tunables and let's work to make 
the VM more extendable to serve those workloads well.  This should be done 
by showing how background reclaim is ineffective, we enter direct 
compaction or reclaim too aggressively, we don't wait for writeout long 
enough, we prematurely kill applications when unnecessary, etc, which 
would undoubtedly have if you're going to make any sane adjustments via 
these new tunables.
--
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/