On Fri, 26 Jan 2018, Michal Hocko wrote:
> > Could you elaborate on why specifying the oom policy for the entire
> > hierarchy as part of the root mem cgroup and also for individual subtrees
> > is incomplete? It allows admins to specify and delegate policy decisions
> > to subtrees owners as
On Thu 25-01-18 15:27:29, David Rientjes wrote:
> On Thu, 25 Jan 2018, Michal Hocko wrote:
>
> > > As a result, this would remove patch 3/4 from the series. Do you have
> > > any
> > > other feedback regarding the remainder of this patch series before I
> > > rebase it?
> >
> > Yes, and I hav
On Thu, 25 Jan 2018, Michal Hocko wrote:
> > As a result, this would remove patch 3/4 from the series. Do you have any
> > other feedback regarding the remainder of this patch series before I
> > rebase it?
>
> Yes, and I have provided it already. What you are proposing is
> incomplete at best
On Wed 24-01-18 14:08:05, Andrew Morton wrote:
[...]
> Can we please try to narrow the scope of this issue by concentrating on
> the userspace interfaces? David believes that the mount option and
> memory.oom_group will disappear again in the near future, others
> disagree.
Mount option is the cg
On Wed 24-01-18 13:44:02, David Rientjes wrote:
> On Wed, 24 Jan 2018, Michal Hocko wrote:
>
> > > The current implementation of memory.oom_group is based on top of a
> > > selection implementation that is broken in three ways I have listed for
> > > months:
> >
> > This doesn't lead to anywher
Hello, Andrew.
On Wed, Jan 24, 2018 at 02:08:05PM -0800, Andrew Morton wrote:
> Can we please try to narrow the scope of this issue by concentrating on
> the userspace interfaces? David believes that the mount option and
> memory.oom_group will disappear again in the near future, others
> disagre
On Wed, 24 Jan 2018 13:44:02 -0800 (PST) David Rientjes
wrote:
> On Wed, 24 Jan 2018, Michal Hocko wrote:
>
> > > The current implementation of memory.oom_group is based on top of a
> > > selection implementation that is broken in three ways I have listed for
> > > months:
> >
> > This doesn
On Wed, 24 Jan 2018, Michal Hocko wrote:
> > The current implementation of memory.oom_group is based on top of a
> > selection implementation that is broken in three ways I have listed for
> > months:
>
> This doesn't lead to anywhere. You are not presenting any new arguments
> and you are igno
On Tue 23-01-18 14:22:07, David Rientjes wrote:
> On Tue, 23 Jan 2018, Michal Hocko wrote:
>
> > > It can't, because the current patchset locks the system into a single
> > > selection criteria that is unnecessary and the mount option would become
> > > a
> > > no-op after the policy per subtre
On Tue, 23 Jan 2018, Michal Hocko wrote:
> > It can't, because the current patchset locks the system into a single
> > selection criteria that is unnecessary and the mount option would become a
> > no-op after the policy per subtree becomes configurable by the user as
> > part of the hierarchy
On Mon 22-01-18 14:34:39, David Rientjes wrote:
> On Sat, 20 Jan 2018, Tejun Heo wrote:
[...]
> > I don't see any blocker here. The issue you're raising can and should
> > be handled separately.
> >
>
> It can't, because the current patchset locks the system into a single
> selection criteria t
On Wed 17-01-18 14:18:33, David Rientjes wrote:
> On Wed, 17 Jan 2018, Michal Hocko wrote:
>
> > Absolutely agreed! And moreover, there are not all that many ways what
> > to do as an action. You just kill a logical entity - be it a process or
> > a logical group of processes. But you have way too
On Sat, 20 Jan 2018, Tejun Heo wrote:
> > Hearing no response, I'll implement this as a separate tunable in a v2
> > series assuming there are no better ideas proposed before next week. One
> > of the nice things about a separate tunable is that an admin can control
> > the overall policy and
Hello, David.
On Fri, Jan 19, 2018 at 12:53:41PM -0800, David Rientjes wrote:
> Hearing no response, I'll implement this as a separate tunable in a v2
> series assuming there are no better ideas proposed before next week. One
> of the nice things about a separate tunable is that an admin can co
On Wed, 17 Jan 2018, David Rientjes wrote:
> Yes, this is a valid point. The policy of "tree" and "all" are identical
> policies and then the mechanism differs wrt to whether one process is
> killed or all eligible processes are killed, respectively. My motivation
> for this was to avoid havi
On Wed, 17 Jan 2018, Michal Hocko wrote:
> Absolutely agreed! And moreover, there are not all that many ways what
> to do as an action. You just kill a logical entity - be it a process or
> a logical group of processes. But you have way too many policies how
> to select that entity. Do you want to
On Wed, 17 Jan 2018, Tejun Heo wrote:
> Hello, David.
>
Hi Tejun!
> > The behavior of killing an entire indivisible memory consumer, enabled
> > by memory.oom_group, is an oom policy itself. It specifies that all
>
> I thought we discussed this before but maybe I'm misremembering.
> There are
On Wed 17-01-18 07:41:55, Tejun Heo wrote:
> Hello, David.
>
> On Tue, Jan 16, 2018 at 06:15:08PM -0800, David Rientjes wrote:
> > The behavior of killing an entire indivisible memory consumer, enabled
> > by memory.oom_group, is an oom policy itself. It specifies that all
>
> I thought we discu
Hello, David.
On Tue, Jan 16, 2018 at 06:15:08PM -0800, David Rientjes wrote:
> The behavior of killing an entire indivisible memory consumer, enabled
> by memory.oom_group, is an oom policy itself. It specifies that all
I thought we discussed this before but maybe I'm misremembering.
There are
The behavior of killing an entire indivisible memory consumer, enabled
by memory.oom_group, is an oom policy itself. It specifies that all
usage should be accounted to an ancestor and, if selected by the cgroup
aware oom killer, all processes attached to it and its descendant mem
cgroups should be
20 matches
Mail list logo
