linux-kernel - Re: [RFC 1/3] /dev/low_mem

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:	Tue, 17 Jan 2012 14:30:30 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Pekka Enberg <penberg@...nel.org>
CC:	Minchan Kim <minchan@...nel.org>, linux-mm <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>, leonid.moiseichuk@...ia.com,
	kamezawa.hiroyu@...fujitsu.com, mel@....ul.ie, rientjes@...gle.com,
	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ronen Hod <rhod@...hat.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [RFC 1/3] /dev/low_mem_notify

On 01/17/2012 01:51 PM, Pekka Enberg wrote:
> Hello,
>
> Ok, so here's a proof of concept patch that implements sample-base
> per-process free threshold VM event watching using perf-like syscall
> ABI. I'd really like to see something like this that's much more
> extensible and clean than the /dev based ABIs that people have proposed
> so far.

Looks like a nice extensible interface to me.

The only thing is, I expect we will not want to wake
up processes most of the time, when there is no memory
pressure, because that would just waste battery power
and/or cpu time that could be used for something else.

The desire to avoid such wakeups makes it harder to
wake up processes at arbitrary points set by the API.

Another issue is that we might be running two programs
on the system, each with a different threshold for
"lets free some of my cache".  Say one program sets
the threshold at 20% free/cache memory, the other
program at 10%.

We could end up with the first process continually
throwing away its caches, while the second process
never gives its unused memory back to the kernel.

I am not sure what the right thing to do would be...

-- 
All rights reversed
--
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/