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]

Message-Id: <20090122114955.32F3.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date:	Wed, 21 Jan 2009 11:50:48 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Greg KH <greg@...ah.com>
Cc:	kosaki.motohiro@...fujitsu.com, Paul Mundt <lethal@...ux-sh.org>,
	Trilok Soni <soni.trilok@...il.com>,
	Arve Hj?nnev?g <arve@...roid.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Pavel Machek <pavel@...e.cz>,
	Brian Swetland <swetland@...gle.com>, arve@...gle.com,
	San Mehat <san@...roid.com>, Robert Love <rlove@...gle.com>,
	linux-kernel@...r.kernel.org,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	Tony Lindgren <tony@...mide.com>,
	ext Juha Yrj?l? <juha.yrjola@...idboot.com>,
	viktor.rosendahl@...ia.com
Subject: Re: lowmemory android driver not needed?

> On Fri, Jan 16, 2009 at 08:16:51PM +0900, KOSAKI Motohiro wrote:
> > 
> > As far as I know, embedded guys strong want to lowmem notification mecanism.
> 
> I think the big server guys also want the same thing :)

Yeah! I know, because my company is definitry big server vendor :)

> > At least, I and my mem_notify receive multiple contact from embedded
> > and JavaVM developer.
> >  (include sun javavm engineer)
> > 
> > In ideal, I think linux MM should care this requirement directly.
> 
> I agree.
> 
> > LSM and driver notifier is easy breakable because these component
> > deeply depend on MM.
> 
> Agreed.
> 
> > (eg, I developed /dev/mem_notify patch last year. but this patch don't
> > work on 2.6.28 because split-lru patch series totally changed MM
> > reclaim processing.)
> > 
> > Unfortunately, we don't have any consensus of memory notification requirement.
> > various people have various requirement. so, if I can discuss it and
> > we get consensus, I'm glad.
> 
> Care to work on your mem_notify patch again and bring it up to date?
> That would be a good place to start working from, right?

Unfortunately No ;)

I should rewrite memory notification patchset from scratch.
the new version will construct on memcg infrastrcture.

Why?

last year, I received many feedback from lkml folks and my article reader.
(I monthly write kernel patch introduction article to japanese web
 magazine and receive some feedback periodically)

I learned many people want flexibility notification.
(per workload, per user, et al)
eg. nokia lowmem driver have exception process defined by uid.

at top of last year, I thought memcg don't provide good infrastructure.
the first version memcg is just pretty funny joke. if its config turn on,
memory workload performance decrease ~30% although the user don't use 
memcg at runtime. then nobody use it.
but recently, KAMEZAWA hiroyuki (and Li zefan, Daisuke Nishimura et al)
dramatically improvement memcg performance. 
now, memcg overhead become less than 1%. 

Then, I think any memory accounting activity should use this infrastructure.
That's my homework.

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