On Wednesday 28 January 2009 06:30:42 Paul Menage wrote:
> Hi Nikanth,
>
> On Fri, Jan 23, 2009 at 6:56 AM, Nikanth Karthikesan
wrote:
> > From: Nikanth Karthikesan
> >
> > Cgroup based OOM killer controller
> >
> > Signed-off-by: Nikanth Karthikesan
On Tuesday 27 January 2009 16:51:26 David Rientjes wrote:
> On Tue, 27 Jan 2009, Nikanth Karthikesan wrote:
> > > I don't understand what you're arguing for here. Are you suggesting
> > > that we should not prefer tasks that intersect the set of allowable
> >
On Tuesday 27 January 2009 16:23:00 David Rientjes wrote:
> On Tue, 27 Jan 2009, Nikanth Karthikesan wrote:
> > > As previously stated, I think the heuristic to penalize tasks for not
> > > having an intersection with the set of allowable nodes of the oom
> > >
On Saturday 24 January 2009 02:14:59 David Rientjes wrote:
> On Fri, 23 Jan 2009, Nikanth Karthikesan wrote:
> > In other instances, It can actually also kill some innocent tasks unless
> > the administrator tunes oom_adj, say something like kvm which would have
> > a huge
On Friday 23 January 2009 16:03:49 David Rientjes wrote:
> On Fri, 23 Jan 2009, Nikanth Karthikesan wrote:
> > > Of course, because the oom killer must be aware that tasks in disjoint
> > > cpusets are more likely than not to result in no memory freeing for
> > > cu
On Thursday 22 January 2009 15:57:19 David Rientjes wrote:
> On Thu, 22 Jan 2009, Evgeniy Polyakov wrote:
> > > In an exclusive cpuset, a task's memory is restricted to a set of mems
> > > that the administrator has designated. If it is oom, the kernel must
> > > free memory on those nodes or the
On Thursday 22 January 2009 15:09:28 David Rientjes wrote:
> On Thu, 22 Jan 2009, Nikanth Karthikesan wrote:
> > > You can't specify different behavior for an oom cgroup depending on
> > > what type of oom it is, which is the problem with this proposal.
> >
> &
On Thursday 22 January 2009 14:13:38 David Rientjes wrote:
> On Thu, 22 Jan 2009, Nikanth Karthikesan wrote:
> > No, this is not specific to memcg or cpuset cases alone. The same
> > needless kills will take place even without memcg or cpuset when an
> > administrator spe
On Thursday 22 January 2009 11:59:20 Arve Hjønnevåg wrote:
> On Wed, Jan 21, 2009 at 10:12 PM, Nikanth Karthikesan
wrote:
> > On Thursday 22 January 2009 11:09:45 Arve Hjønnevåg wrote:
> >> On Wed, Jan 21, 2009 at 9:13 PM, Nikanth Karthikesan
> >
> > wrote:
> &g
On Thursday 22 January 2009 10:57:21 KAMEZAWA Hiroyuki wrote:
> On Thu, 22 Jan 2009 10:43:12 +0530
>
> Nikanth Karthikesan wrote:
> > On Thursday 22 January 2009 08:58:43 KAMEZAWA Hiroyuki wrote:
> > > On Wed, 21 Jan 2009 16:38:21 +0530
> > >
> > > Nikan
On Thursday 22 January 2009 11:09:45 Arve Hjønnevåg wrote:
> On Wed, Jan 21, 2009 at 9:13 PM, Nikanth Karthikesan
wrote:
> > To use oom_adj effectively one should continuously monitor oom_score of
> > all the processes, which is a complex moving target and keep on adjusting
>
On Thursday 22 January 2009 08:58:43 KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jan 2009 16:38:21 +0530
>
> Nikanth Karthikesan wrote:
> > As Alan Cox suggested/wondered in this thread,
> > http://lkml.org/lkml/2009/1/12/235 , this is a container group based
> > approach
On Thursday 22 January 2009 08:23:24 KAMEZAWA Hiroyuki wrote:
> On Wed, 21 Jan 2009 12:49:50 -0800 (PST)
>
> David Rientjes wrote:
> > On Wed, 21 Jan 2009, Nikanth Karthikesan wrote:
> > > This is a container group based approach to override the oom killer
> > >
On Thursday 22 January 2009 02:19:50 David Rientjes wrote:
> On Wed, 21 Jan 2009, Nikanth Karthikesan wrote:
> > This is a container group based approach to override the oom killer
> > selection without losing all the benefits of the current oom killer
> > heuristics
On Wednesday 21 January 2009 18:47:39 Evgeniy Polyakov wrote:
> On Wed, Jan 21, 2009 at 04:38:21PM +0530, Nikanth Karthikesan
(knika...@suse.de) wrote:
> > As Alan Cox suggested/wondered in this thread,
> > http://lkml.org/lkml/2009/1/12/235 , this is a container group based
cgroup. The oom killer will kill the
process using the usual badness value but only within the cgroup with the
maximum value for oom.victim before killing any process from a cgroup with a
lesser oom.victim number. Oom killing could be disabled by setting
oom.victim=0.
Signed-off-by: Nikanth
On Monday 01 December 2008 06:42:08 KAMEZAWA Hiroyuki wrote:
> On Sat, 29 Nov 2008 12:59:27 +0530
>
> Nikanth Karthikesan <[EMAIL PROTECTED]> wrote:
> > Currently we just check for thread group leader in attach() handler but
> > do nothing! Either (1) move it to can_a
Currently we just check for thread group leader in attach() handler but do
nothing! Either (1) move it to can_attach handler or (2) remove the test
itself. I am attaching patches for both below.
Thanks
Nikanth Karthikesan
Move thread group leader check to can_attach handler, but this may
On Mon, 2008-04-07 at 22:43 -0700, Paul Menage wrote:
> On Mon, Apr 7, 2008 at 10:39 PM, Nikanth Karthikesan <[EMAIL PROTECTED]>
> wrote:
> >
> > Why not provide a interface to add subsystems at run-time instead?
> > Are there any reason for not letting a su
gt; > I don't know what this is, but it does not look like C...
> > >
> > > Huh?
> >
> > Empty comments as separators?
>
> They help when multiple people add such SUBSYS things and
> do not have to fight rejects.
>
Why not provide a interface
20 matches
Mail list logo
