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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.00.1110131351270.24853@chino.kir.corp.google.com>
Date:	Thu, 13 Oct 2011 13:55:46 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
cc:	Satoru Moriya <satoru.moriya@....com>,
	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-mm@...ck.org,
	"lwoodman@...hat.com" <lwoodman@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	Hugh Dickins <hughd@...gle.com>, hannes@...xchg.org
Subject: Re: [PATCH -v2 -mm] add extra free kbytes tunable

On Thu, 13 Oct 2011, KAMEZAWA Hiroyuki wrote:

> sys_mem_shrink(int nid, int nr_scan_pages, int flags)
> 
> This system call scans LRU of specified nodes and free pages on LRU.
> This scan nr_scan_pages in LRU and returns the number of successfully
> freed pages.
> ==
> 
> Then, running this progam in SCHED_IDLE, a user can make free pages while
> the system is idle. If running in the highest priority, a user can keep
> free pages as he want. If a user run this under a memcg, user can free
> pages in a memcg. 
> 

Satoru was specifically talking about the VM using free memory for 
pagecache, so doing echo echo 1 > /proc/sys/vm/drop_caches can mitigate 
that almost immediately.  I think the key to the discussion, though, is 
that even the application doesn't know it's bursty memory behavior before 
it happens and the kernel entering direct reclaim hurts latency-sensitive 
applications.

If there were a change to increase the space significantly between the 
high and min watermark when min_free_kbytes changes, that would fix the 
problem.  The problem is two-fold: that comes at a penalty for systems 
or workloads that don't need to reclaim the additional memory, and it's 
not clear how much space should exist between those watermarks.
--
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/