Quoting Paul Menage (men...@google.com):
> cgroup: Fix root_count when mount fails due to busy subsystem
>
> root_count was being incremented in cgroup_get_sb() after all error
> checking was complete, but decremented in cgroup_kill_sb(), which can
> be called on a superblock that we gave up on du
Quoting Paul Menage (men...@google.com):
> On Thu, Jan 22, 2009 at 10:47 AM, Serge E. Hallyn wrote:
> > #!/bin/bash
> > mount -t cgroup -o freezer none /cgroup
> > sleep 100 &
> > pid=`jobs -p`
>
> You can use $! to refer to the most recently started background process.
Hah - thanks, I actually
On Thu, Jan 22, 2009 at 5:26 PM, Matt Helsley wrote:
>
>I see what you mean. I am still mystified how rcu_read_lock() around
> the cgroup iterator in cgroupstats_build() hid/prevented the problem
> though :/.
I think the problem was in git bisect - the problematic commit was a
couple late
On Thu, 2009-01-22 at 16:26 -0800, Paul Menage wrote:
> On Thu, Jan 22, 2009 at 3:35 PM, Paul Menage wrote:
> > On Thu, Jan 22, 2009 at 3:07 PM, Paul Menage wrote:
> >>> mount -t cgroup -o freezer,ns none /cgroup
> >>
> >> This command should have failed with EBUSY, since freezer is already
> >>
On Thu, Jan 22, 2009 at 10:47 AM, Serge E. Hallyn wrote:
> The following script gives me a reliable BUG bisected to
> commit 7534432dcc3c654a8671b6b0cdffd1dbdbc73074, subject
> "cgroups: remove rcu_read_lock() in cgroupstats_build()".
> It's not immediately clear to me why that commit should
> cau
cgroup: Fix root_count when mount fails due to busy subsystem
root_count was being incremented in cgroup_get_sb() after all error
checking was complete, but decremented in cgroup_kill_sb(), which can
be called on a superblock that we gave up on due to an error. This
patch changes cgroup_kill_sb()
On Thu, Jan 22, 2009 at 3:35 PM, Paul Menage wrote:
> On Thu, Jan 22, 2009 at 3:07 PM, Paul Menage wrote:
>>> mount -t cgroup -o freezer,ns none /cgroup
>>
>> This command should have failed with EBUSY, since freezer is already
>> part of an existing hierarchy. So I think it's a red herring in th
On Thu, Jan 22, 2009 at 3:07 PM, Paul Menage wrote:
>> mount -t cgroup -o freezer,ns none /cgroup
>
> This command should have failed with EBUSY, since freezer is already
> part of an existing hierarchy. So I think it's a red herring in this
> problem.
But in fact taking out this line does stop t
On Fri, Jan 23, 2009 at 01:53:04AM +0300, Evgeniy Polyakov (z...@ioremap.net)
wrote:
> > I'm quite certain you've spent more time writing emails to me than merging
> > the patch and testing its possibilities, given your lack of understanding
> > of its very basic concepts.
>
> How cute :)
> Any
On Thu, Jan 22, 2009 at 10:47 AM, Serge E. Hallyn wrote:
> #!/bin/bash
> mount -t cgroup -o freezer none /cgroup
> sleep 100 &
> pid=`jobs -p`
You can use $! to refer to the most recently started background process.
> mkdir /cgroup/1
> echo $pid > /cgroup/1/tasks
> umount /cgroup
> mount -t cgro
On Thu, Jan 22, 2009 at 02:28:11PM -0800, David Rientjes (rient...@google.com)
wrote:
> > And returning to the oom_adj and cpusets tunables. Why any new process
> > started in given cpuset can not be tuned by external application or some
> > script to have bigger/smaller oom_adj parameter? :)
>
>
On Fri, 23 Jan 2009, Evgeniy Polyakov wrote:
> I showed the case when it does not work at all. And then found (in this
> mail), that task (part) has to be present in the memory, which means it
> will be locked, which in turns will not work with the system which
> already locked its range allowed b
On Thu, Jan 22, 2009 at 01:35:13PM -0800, David Rientjes (rient...@google.com)
wrote:
> > And that is The Main Point. Not to help some subsystem, but be useful
> > for others. It is different tunable. It has really nothing with cpusets.
>
> It doesn't work with any system that is running with cpu
On Fri, 23 Jan 2009, Evgeniy Polyakov wrote:
> Only the fact that cpusets have _very_ special meaning in the oom-killer
> codepath, while it should be just another tunable (if it should be
> special code at all at the first place, why there were no objection and
> argument, that tasks could have d
On Thu, Jan 22, 2009 at 12:28:45PM -0800, David Rientjes (rient...@google.com)
wrote:
> I don't know what you're talking about, cpusets are simply a client of the
> cgroup interface.
Only the fact that cpusets have _very_ special meaning in the oom-killer
codepath, while it should be just anothe
On Thu, 22 Jan 2009, Evgeniy Polyakov 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
> > current's subsequent allocations.
>
> And if we replace cpuset with cgroup (or anything else), noth
The following script gives me a reliable BUG bisected to
commit 7534432dcc3c654a8671b6b0cdffd1dbdbc73074, subject
"cgroups: remove rcu_read_lock() in cgroupstats_build()".
It's not immediately clear to me why that commit should
cause this...
thanks,
-serge
On Tue, Jan 20, 2009 at 03:53:34PM +, Alasdair G Kergon wrote:
> So, what needs to be reviewed?
>
>
> 1. General style/layout/naming cleanup.
> - It's pretty good compared to a lot of patches that get sent, but there are
> still a few things we can improve.
>
> Lindent is throwing up some st
On Thu, Jan 22, 2009 at 02:27:19AM -0800, David Rientjes (rient...@google.com)
wrote:
> > The whole point of oom-killer is to kill the most appropriate task to
> > free the memory. And while task is selected system-wide and some
> > tunables are added to tweak the behaviour local to some subsystem
On Thu, Jan 22, 2009 at 02:00:55AM -0800, David Rientjes (rient...@google.com)
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 next allocation will again
On Thu, Jan 22, 2009 at 12:43:38AM -0800, David Rientjes (rient...@google.com)
wrote:
> For example, if your task triggers an oom as the result of its exclusive
> cpuset placement, the oom killer should prefer to kill a task within that
> cpuset to allow for future memory freeing.
This it not t
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:
>> > To use oom_adj effectively one should continuously monitor oom_score of
>> > all the processes, which is
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 the
> oom_adj of many tasks which still cannot guarantee the order. This controller
> is
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 approach
> to override the oom killer selection without losing all the benefits of the
On Sat, Jan 17, 2009 at 3:26 PM, Sukadev Bhattiprolu
wrote:
>
> Container-init must behave like global-init to processes within the
> container and hence it must be immune to unhandled fatal signals from
> within the container (i.e SIG_DFL signals that terminate the process).
>
> But the same cont
Cyrill Gorcunov wrote:
In PPPo[E|L2TP] we could explicitly point which net namespace
we're going to use for channels - make it so.
Hi Cyrill,
For some reason, I see your your mail' date pointing to 12/31/1969.
Cheers,
Divy
___
Devel mailing lis
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 next allocation will again trigger an oom
> > (leading to a nee
On Thu, 22 Jan 2009, Nikanth Karthikesan wrote:
> I think cpusets preference could be improved, not to depend on badness, with
> something similar to what memcg does. With or without adding overhead of
> tracking processes that has memory from a node.
>
We actually used to do that: we excluded
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.
> >
> > No. This does not disable any such sp
On Thu, 22 Jan 2009, Evgeniy Polyakov wrote:
> > For example, if your task triggers an oom as the result of its exclusive
> > cpuset placement, the oom killer should prefer to kill a task within that
> > cpuset to allow for future memory freeing.
>
> This it not true for all cases. What if you
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.
> >
>
> No. This does not disable any such special selection criteria which is used
> without this controll
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 specifies a light memory consu
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
> specifies a light memory consumer to be killed before a heavy memory user.
> But
> it is up
33 matches
Mail list logo
