[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread David Rientjes
On Tue, 27 Jan 2009, KOSAKI Motohiro wrote: > Yup, indeed. :) > honestly, I talked about the same thingk recently "lowmemory android driver > not needed?" thread. > Yeah, I proposed /dev/mem_notify being made as a client of cgroups there in http://marc.info/?l=linux-kernel&m=123200623628685 H

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread KOSAKI Motohiro
> On Tue, 27 Jan 2009, KOSAKI Motohiro wrote: > > > Confused. > > > > As far as I know, people want the method of flexible cache treating. > > but oom seems less flexible than userland notification. > > > > Why do you think notification is bad? > > > > There're a couple of proposals that have

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread David Rientjes
On Tue, 27 Jan 2009, KOSAKI Motohiro wrote: > Confused. > > As far as I know, people want the method of flexible cache treating. > but oom seems less flexible than userland notification. > > Why do you think notification is bad? > There're a couple of proposals that have been discussed recentl

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread Balbir Singh
* KOSAKI Motohiro [2009-01-27 16:02:34]: > Hi > > > > > As Alan Cox suggested/wondered in this thread, > > > > http://lkml.org/lkml/2009/1/12/235 , this is a container group based > > > > approach > > > > to override the oom killer selection without losing all the benefits of > > > > the >

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread KOSAKI Motohiro
Hi > > > As Alan Cox suggested/wondered in this thread, > > > http://lkml.org/lkml/2009/1/12/235 , this is a container group based > > > approach > > > to override the oom killer selection without losing all the benefits of > > > the > > > current oom killer heuristics and oom_adj interface.

[Devel] Re: [PATCH 2/3] ipc namespaces: implement support for posix msqueues

2009-01-26 Thread Andrew Morton
On Fri, 16 Jan 2009 20:03:32 -0600 "Serge E. Hallyn" wrote: > Implement multiple mounts of the mqueue file system, and > link it to usage of CLONE_NEWIPC. > > Each ipc ns has a corresponding mqueuefs superblock. When > a user does clone(CLONE_NEWIPC) or unshare(CLONE_NEWIPC), the > unshare will

[Devel] Re: [PATCH 1/3] mqueue ns: move mqueue_mnt into struct ipc_namespace

2009-01-26 Thread Andrew Morton
On Fri, 16 Jan 2009 20:03:22 -0600 "Serge E. Hallyn" wrote: > Move mqueue vfsmount plus a few tunables into the > ipc_namespace struct. The CONFIG_IPC_NS boolean > and the ipc_namespace struct will serve both the > posix message queue namespaces and the SYSV ipc > namespaces. > > > ... > > ---

[Devel] Re: [Patch 0/3] posix mqueue namespace (v14)

2009-01-26 Thread Andrew Morton
On Fri, 16 Jan 2009 20:02:48 -0600 "Serge E. Hallyn" wrote: > IPC namespaces are completely disjoint id->object mappings. > A task can pass CLONE_NEWIPC to unshare and clone to get > a new, empty, IPC namespace. Until now this has supported > SYSV IPC. > > Most Posix IPC is done in userspace.

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread Alan Cox
On Tue, 27 Jan 2009 01:24:31 +0530 Balbir Singh wrote: > * Nikanth Karthikesan [2009-01-21 16:38:21]: > > > As Alan Cox suggested/wondered in this thread, > > http://lkml.org/lkml/2009/1/12/235 , this is a container group based > > approach > > to override the oom killer selection without lo

[Devel] Re: [RFC] [PATCH] Cgroup based OOM killer controller

2009-01-26 Thread Balbir Singh
* Nikanth Karthikesan [2009-01-21 16:38:21]: > As Alan Cox suggested/wondered in this thread, > http://lkml.org/lkml/2009/1/12/235 , this is a container group based approach > to override the oom killer selection without losing all the benefits of the > current oom killer heuristics and oom_ad

[Devel] Re: [dm-devel] [PATCH 1/2] dm-ioband: I/O bandwidth controller v1.10.0: Source code and patch

2009-01-26 Thread Vivek Goyal
On Fri, Jan 23, 2009 at 07:14:04PM +0900, Ryo Tsuruta wrote: > Hi Vivek, > > Thanks for your comments. > > > I am not very sure why dm-ioband folks want to enable IO control on any > > xyz block device but in the past I got two responses. > > > > 1. Need to control end devices which don't have a