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 03:06:20 -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 Fri, 13 Jan 2012, leonid.moiseichuk@...ia.com wrote:

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

I'm trying to make this easy for you, if you haven't noticed.  Your memory 
threshold, as proposed, will have values that are tied directly to the 
implementation of the VM in the kernel when its under memory pressure and 
that implementation evolves at a constant rate.

What I'm proposing is limiting the amount of latency that the VM incurs 
when under memory pressure, notify userspace, and allow it to react to the 
situation until the delay expires.  This doesn't require recalibration for 
other products or upgraded kernels, it just works all the time.

> Slowdown is natural thing if you have lack of space for code paging, I 
> do not see any ways to fix it.
> 

mlock() the memory that your userspace monitoring needs to send signals to 
applications, whether those signals are handled to free memory internally 
or its SIGTERM or SIGKILL.
--
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/