On Mon, 23 Jul 2018, Roman Gushchin wrote:
> > Roman, I'm trying to make progress so that the cgroup aware oom killer is
> > in a state that it can be merged. Would you prefer a second tunable here
> > to specify a cgroup's points includes memory from its subtree?
>
> Hi, David!
>
> It's hard
On Mon, Jul 23, 2018 at 01:33:19PM -0700, David Rientjes wrote:
> On Mon, 16 Jul 2018, David Rientjes wrote:
>
> > > And "tree" is different. It actually changes how the selection algorithm
> > > works,
> > > and sub-tree settings do matter in this case.
> > >
> >
> > "Tree" is considering the
On Mon, 16 Jul 2018, David Rientjes wrote:
> > And "tree" is different. It actually changes how the selection algorithm
> > works,
> > and sub-tree settings do matter in this case.
> >
>
> "Tree" is considering the entity as a single indivisible memory consumer,
> it is compared with siblings
On Mon, 16 Jul 2018, Roman Gushchin wrote:
> Hello, David!
>
> I think that there is an inconsistency in the memory.oom_policy definition.
> "none" and "cgroup" policies defining how the OOM scoped to this particular
> memory cgroup (or system, if set on root) is handled. And all sub-tree
> setti
On Fri, Jul 13, 2018 at 04:07:29PM -0700, David Rientjes wrote:
> One of the three significant concerns brought up about the cgroup aware
> oom killer is that its decisionmaking is completely evaded by creating
> subcontainers and attaching processes such that the ancestor's usage does
> not exceed
One of the three significant concerns brought up about the cgroup aware
oom killer is that its decisionmaking is completely evaded by creating
subcontainers and attaching processes such that the ancestor's usage does
not exceed another cgroup on the system.
Consider the example from the previous p
6 matches
Mail list logo
