linux-kernel - Re: lowmemory android driver not needed?

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:	Wed, 14 Jan 2009 23:55:54 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Pavel Machek <pavel@...e.cz>, Greg KH <greg@...ah.com>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Brian Swetland <swetland@...gle.com>, arve@...gle.com,
	San Mehat <san@...roid.com>, Robert Love <rlove@...gle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: lowmemory android driver not needed?

On Wed, 14 Jan 2009, Alan Cox wrote:

> I was thinking that, and it would integrate better with the OLPC work
> (which IMHO is a nicer interface for some stuff)
> 
> You'd want two thresholds
> 
> The 'arghhhh....' point where you start killing stuff
> The 'uh oh...' point where an OLPC style low memory notifier kicks in
> 
> (OLPC's model is a handle you can select/poll for 'memory getting low' so
> apps can respond to pressure by doing stuff like dumping caches)
> 
> The rest ought to follow naturally IFF you can find a clean efficient way
> to measure that pressure and quantify it as a number. Our default would
> be like now, the Android default might be to trigger earlier..

The /dev/mem_notify patch allowed polling on a system-wide scale for low 
memory conditions so that userspace could respond appropriately: either by 
droping caches, as you mentioned, or sending a signal.  That signal could 
quite possibily be SIGKILL for no better reason than preempting what the 
kernel oom killer would do.

I think this should be completely seperate from the oom killer, which has 
always been a "last resort" to situations where the kernel is completely 
out of memory for a task.

If /dev/mem_notify existed in a cgroup form so that different handlers 
could be responsible for an aggregate of tasks, I think this addresses 
your concerns.  That might require some cleverness in the cgroup 
filesystem code if this would introduce device files, but there are 
probably future use cases for that, as well.
--
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/