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:	Fri, 13 Jan 2012 09:34:40 +0000
From:	<leonid.moiseichuk@...ia.com>
To:	<rientjes@...gle.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

> -----Original Message-----
> From: ext David Rientjes [mailto:rientjes@...gle.com]
> Sent: 12 January, 2012 21:55
> To: Moiseichuk Leonid (Nokia-MP/Helsinki)
....
> 
> 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.

Why? That is expected that product tested and tuned properly, applications fixed, and at least no apps installed which might consume 100 MB in second or two.
If you have another product with big difference in memory size, applications etc. you might need to re-calibrate reactions.
Let's focus on realistic cases.

> 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.

That is not possible - signals usually set at level you have 20-50 MB to react. 
Slowdown is natural thing if you have lack of space for code paging, I do not see any ways to fix it.

>  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.

It is not necessary.

> 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.

Define "lowmem situation" first.  For proposed approach it is from 50-90% of memory usage until user-space can do something.
--
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/