linux-kernel - Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize in lowmem

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] [day] [month] [year] [list]

Date:	Mon, 22 Feb 2016 16:54:35 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Xishi Qiu <qiuxishi@...wei.com>
cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, arve@...roid.com,
	riandrews@...roid.com, devel@...verdev.osuosl.org,
	zhong jiang <zhongjiang@...wei.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux MM <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: add MM_SWAPENTS and page table when calculate tasksize
 in lowmem_scan()

On Thu, 18 Feb 2016, Xishi Qiu wrote:

> Does somebody do the work of re-implementation of the lowmem killer entirely
> now? Could you give me some details? e.g. when and how?
> 

I don't know of any plans or anybody working on reimplementing it to be 
correct, I simply don't think we should pile more patches on top of an 
already broken design.

> Here are another two questions.
> 1) lmk has several lowmem thresholds, it's "lowmem_minfree[]", and the value is
> static definition, so is it reasonable for different memory size(e.g. 2G/3G/4G...)
> of smart phones?

It looks like it is configurable from userspace and actually defaults to 
6MB, 8MB, 16MB, and 64MB in the kernel.  Reimplementing the lmk would have 
to take this design decision into consideration and replace it with 
something that would not cause existing userspace to break.

A sane implementation would be to do what vmpressure does in the kernel, 
and that is to signal userspace when certain thresholds are met.  
Userspace could then issue a SIGKILL to processes based on priority 
(/proc/pid/oom_score_adj is world-readable by default) and the oom killer 
will grant these processes access to memory reserves immediately if they 
cannot allocate the memory needed to exit.

> 2) There are many adjustable arguments in /proc/sys/vm/, and the default value
> maybe not benefit for smart phones, so any suggestions?
> 

I would assume that vm sysctls, like any other sysctls, would be tuned 
with initscripts depending on the configuration, if necessary.