linux-kernel - RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

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]

Date:	Thu, 12 Jan 2012 12:54:50 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	leonid.moiseichuk@...ia.com
cc:	gregkh@...e.de, linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	cesarb@...arb.net, kamezawa.hiroyu@...fujitsu.com,
	emunson@...bm.net, penberg@...nel.org, aarcange@...hat.com,
	riel@...hat.com, mel@....ul.ie, dima@...roid.com,
	rebecca@...roid.com, san@...gle.com, akpm@...ux-foundation.org,
	vesa.jaaskelainen@...ia.com
Subject: RE: [PATCH 3.2.0-rc1 3/3] Used Memory Meter pseudo-device module

On Thu, 12 Jan 2012, leonid.moiseichuk@...ia.com wrote:

> As I wrote the proposed change is not safety belt but looking ahead 
> radar.
> If it detects that we are close to wall it starts to alarm and alarm 
> volume is proportional to distance.
> 

Then it's fundamentally flawed since there's no guarantee that coming with 
100MB of the min watermark, for example, means that an oom is imminent and 
will just result in unnecessary notification to userspace that will cause 
some action to be taken that may not be necessary.  If the setting of 
these thresholds depends on some pattern that is guaranteed to be along 
the path to oom for a certain workload, then that will also change 
depending on VM implementation changes, kernel versions, other 
applications, etc., and simply is unmaintainable.

> In close-to-OOM situations device becomes very slow, which is not good 
> for user. The performance difference depends on code size and storage 
> performance to trash code pages but even 20% is noticeable. Practically 
> 2x-5x times slowdown was observed.
> 

It would be much better to address the slowdown when running out of memory 
rather than requiring userspace to react and unnecessarily send signals to 
threads that may or may not have the ability to respond because they may 
already be oom themselves.  You can do crazy things to reduce latency in 
lowmem memory allocations like changing gfp_allowed_mask to be GFP_ATOMIC 
so that direct reclaim is never called, for example, and then use the 
proposed oom killer delay to handle the situation at the time of oom.

Regardless, you should be addressing the slowness in lowmem situations 
rather than implementing notifiers to userspace to handle the events 
itself, so nack on this proposal.
--
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/