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

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

Message-ID: <alpine.DEB.2.00.1201131328540.24089@chino.kir.corp.google.com>
Date:	Fri, 13 Jan 2012 13:35:23 -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:

> > 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.
> 
> Not sure that I understand this statement. Free/Used/Active page sets 
> are properties of any VM.

The point at which the latency is deemed to be unacceptable in your 
trail-and-error is tied directly to the implementation of the VM and must 
be recalibrated with each userspace change or kernel upgrade.  I assume 
here that some reclaim is allowed in the VM for your usecase; if not, then 
I already gave a solution for how to disable that entirely.

>  The thresholds are set by user-space and individual for applications 
> which likes to be informed.
> 

You haven't given a usecase for the thresholds for anything other than 
when you're just about oom, and I think it's much simpler if you actually 
get to the point of oom and your userspace notifier is guaranteed to be 
able to respond over a preconfigured delay.  It works pretty well for us 
internally, you should consider 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.
> 
> Mlocked memory should be avoid as much as possible because efficiency 
> rate is lowest possible and makes situation for non-mlocked pages even 
> worse.

It's used only to protect the thread that is notified right before the oom 
killer is triggered so that it can send the appropriate signals.  If it 
can't do that, the oom killer delay will expire on subsequent memory 
allocation attempts and kill something itself.  This thread should have a 
minimal memory footprint, be mlock()'d into memory, and have an 
oom_score_adj of OOM_SCORE_ADJ_MIN.
--
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/