From: Paul Mundt <lethal@linux-sh.org>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Greg KH <greg@kroah.com>, Trilok Soni <soni.trilok@gmail.com>,
Arve Hj?nnev?g <arve@android.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Pavel Machek <pavel@suse.cz>,
Brian Swetland <swetland@google.com>,
arve@google.com, San Mehat <san@android.com>,
Robert Love <rlove@google.com>,
linux-kernel@vger.kernel.org,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Tony Lindgren <tony@atomide.com>,
ext Juha Yrj?l? <juha.yrjola@solidboot.com>,
viktor.rosendahl@nokia.com
Subject: Re: lowmemory android driver not needed?
Date: Wed, 21 Jan 2009 12:05:04 +0900 [thread overview]
Message-ID: <20090121030504.GA14094@linux-sh.org> (raw)
In-Reply-To: <20090122114955.32F3.KOSAKI.MOTOHIRO@jp.fujitsu.com>
On Wed, Jan 21, 2009 at 11:50:48AM +0900, KOSAKI Motohiro wrote:
> 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.
>
Building on top of the memory cgroup makes sense given that it has a
lot more knowledge of the actual state in different contexts compared to
something like security_vm_enough_memory()/__vm_enough_memory().
Despite that, a notification layer on top of cgroups in general might be
worth thinking about, particularly since each controller may want to use
notifications for different things. It is conceivable that people will
also want different types of notifications from the memory controller
beyond a simple lowmem notifier.
The LSM lowmem module itself used multiple notification levels to tune
application behaviour for instance, though obviously this is something
that is highly workload dependent.
next prev parent reply other threads:[~2009-01-21 3:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090114010223.GA21380@kroah.com>
[not found] ` <20090114021801.GA14759@bulgaria.corp.google.com>
[not found] ` <d6200be20901131830r7103ff8eoe0314f9faf89d89b@mail.gmail.com>
[not found] ` <20090114035237.GB16442@kroah.com>
[not found] ` <20090114104307.GA20451@elf.ucw.cz>
[not found] ` <20090114104834.18387fca@lxorguk.ukuu.org.uk>
[not found] ` <d6200be20901141426r1d48ea33gc9a380451e4aaf93@mail.gmail.com>
[not found] ` <20090114231739.GB24111@kroah.com>
[not found] ` <d6200be20901141532y6f236104kd521041d640c152e@mail.gmail.com>
[not found] ` <20090115001224.GC11328@kroah.com>
2009-01-15 13:32 ` lowmemory android driver not needed? Trilok Soni
2009-01-15 23:44 ` Greg KH
2009-01-16 9:02 ` Paul Mundt
2009-01-16 11:16 ` KOSAKI Motohiro
2009-01-16 15:23 ` Greg KH
2009-01-21 2:50 ` KOSAKI Motohiro
2009-01-21 3:05 ` Paul Mundt [this message]
2009-01-21 3:29 ` KAMEZAWA Hiroyuki
2009-04-01 18:38 ` Trilok Soni
2009-04-01 19:33 ` David Rientjes
2009-02-03 20:55 ` Tony Lindgren
2009-01-16 11:42 ` KOSAKI Motohiro
2009-01-16 13:18 ` KOSAKI Motohiro
2009-01-22 6:13 ` Arve Hjønnevåg
2009-01-29 1:48 ` KOSAKI Motohiro
2009-01-29 2:51 ` Arve Hjønnevåg
2009-01-29 3:45 ` KAMEZAWA Hiroyuki
2009-01-29 4:27 ` Greg KH
2009-01-29 4:43 ` KOSAKI Motohiro
2009-01-29 4:59 ` Greg KH
2009-01-29 5:29 ` KOSAKI Motohiro
2009-01-30 6:20 ` Greg KH
2009-01-30 6:41 ` Brian Swetland
2009-02-03 13:40 ` KOSAKI Motohiro
2009-01-29 22:06 ` Pavel Machek
2009-02-03 14:08 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090121030504.GA14094@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arve@android.com \
--cc=arve@google.com \
--cc=greg@kroah.com \
--cc=juha.yrjola@solidboot.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=rlove@google.com \
--cc=san@android.com \
--cc=soni.trilok@gmail.com \
--cc=swetland@google.com \
--cc=tony@atomide.com \
--cc=viktor.rosendahl@nokia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox