linux-kernel - RE: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and related changes in MM

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:	Mon, 9 Jan 2012 08:49:41 +0000
From:	<leonid.moiseichuk@...ia.com>
To:	<kosaki.motohiro@...il.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>, <rientjes@...gle.com>, <dima@...roid.com>,
	<rebecca@...roid.com>, <san@...gle.com>,
	<akpm@...ux-foundation.org>, <vesa.jaaskelainen@...ia.com>
Subject: RE: [PATCH 3.2.0-rc1 0/3] Used Memory Meter pseudo-device and
 related changes in MM

> -----Original Message-----
> From: ext KOSAKI Motohiro [mailto:kosaki.motohiro@...il.com]
> Sent: 06 January, 2012 02:27
> To: Moiseichuk Leonid (Nokia-MP/Helsinki)

> > Android OOM (AOOM) is a different thing. Briefly Android OOM is a safety
> belt,
> >but I try to introduce look-ahead radar to stop before hitting wall.
> 
> You explained why we shouldn't merge neither you nor android notification
> patches.
> Many embedded developers tried to merge their own patch and claimed
> "Hey! my patch
> is completely different from another one". That said, their patches can't be
> used
> each other use case, just for them.

Pardon me but these patches doing really different thing. Having notification doesn't mean all you software will handle them correct. In open platform you might have "bad entity" which will be killed by OOM.
In we used default OOM killer but Android OOM probably works better in some other conditions even from my point of view it may trigger false OOMs due to base on NR_FREE_PAGES which are more interesting for kernel for than for user-space. 

> Systemwide global notification itself is not bad idea. But we definitely choose
> just one implementation. thus, you need to get agree with other embedded
> people.

Agree. That is point for discussion. One is already available through memcg but problem is in memcg and how we use it.

> >  UsedMemory = (MemTotal - MemFree - Buffers - Cached - SwapCached) +
> >                                               (SwapTotal - SwapFree)
> 
> If you spent a few time to read past discuttion, you should have understand
> your fomula
> is broken and unacceptable. Think, mlocked (or pinning by other way) cache
> can't be discarded. 

In theory you are right about mlocked pages.  So I will add deduction for NR_MLOCK
In practice typical desktop system has mlocked = 0. Also code pages are shared, so mlocking has 0 effect.
For data pages the some library like http://maemo.gitorious.org/maemo-tools/libmlocknice could be used.
Anyhow, on  n9 we have only  5.3 MB mlocked memory from 1024MB.

> And, When system is under swap thrashing, userland notification is useless.

Well, cgroups CPU shares and ionice seems to me better but as a quick solution extension with LRU_ACTIVE_ANON + LRU_ACTIVE_FILE could be done easily.

>  I don't think you tested w/ swap environment heavily.

n770, n800, n810 have optional in-file swapping.
n900 has permanent 768 MB swap partition.
n9 uses in-RAM lzo compressed 256 MB swap.

All of them tested, tuned and works fine for majority use-cases.

> While you are getting stuck to make nokia specific feature, I'm
> recommending you
> maintain your local patch yourself.

Thanks for advices, but I have better idea which is less destructive for MM.
Maybe it will more successful, at least for maintenance as a local patch.

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