On Fri, 13 Oct 2017, Roman Gushchin wrote:
> > Think about it in a different way: we currently compare per-process usage
> > and userspace has /proc/pid/oom_score_adj to adjust that usage depending
> > on priorities of that process and still oom kill if there's a memory leak.
> > Your heuristi
On Thu, Oct 12, 2017 at 02:50:38PM -0700, David Rientjes wrote:
> On Wed, 11 Oct 2017, Roman Gushchin wrote:
>
> Think about it in a different way: we currently compare per-process usage
> and userspace has /proc/pid/oom_score_adj to adjust that usage depending
> on priorities of that process an
On Wed, 11 Oct 2017, Roman Gushchin wrote:
> > But let's move the discussion forward to fix it. To avoid necessarily
> > accounting memory to the root mem cgroup, have we considered if it is even
> > necessary to address the root mem cgroup? For the users who opt-in to
> > this heuristic, wou
On Wed 11-10-17 13:27:44, David Rientjes wrote:
> On Wed, 11 Oct 2017, Michal Hocko wrote:
>
> > > For these reasons: unfair comparison of root mem cgroup usage to bias
> > > against that mem cgroup from oom kill in system oom conditions, the
> > > ability of users to completely evade the oom ki
On Wed, Oct 11, 2017 at 01:21:47PM -0700, David Rientjes wrote:
> On Tue, 10 Oct 2017, Roman Gushchin wrote:
>
> > > We don't need a better approximation, we need a fair comparison. The
> > > heuristic that this patchset is implementing is based on the usage of
> > > individual mem cgroups. Fo
On Wed, 11 Oct 2017, Michal Hocko wrote:
> > For these reasons: unfair comparison of root mem cgroup usage to bias
> > against that mem cgroup from oom kill in system oom conditions, the
> > ability of users to completely evade the oom killer by attaching all
> > processes to child cgroups eith
On Tue, 10 Oct 2017, Roman Gushchin wrote:
> > We don't need a better approximation, we need a fair comparison. The
> > heuristic that this patchset is implementing is based on the usage of
> > individual mem cgroups. For the root mem cgroup to be considered
> > eligible, we need to understan
On Tue, Oct 10, 2017 at 02:13:00PM -0700, David Rientjes wrote:
> On Tue, 10 Oct 2017, Roman Gushchin wrote:
>
> > > This seems to unfairly bias the root mem cgroup depending on process
> > > size.
> > > It isn't treated fairly as a leaf mem cgroup if they are being compared
> > > based on dif
On Tue 10-10-17 14:13:00, David Rientjes wrote:
[...]
> For these reasons: unfair comparison of root mem cgroup usage to bias
> against that mem cgroup from oom kill in system oom conditions, the
> ability of users to completely evade the oom killer by attaching all
> processes to child cgroups
On Tue, Oct 10, 2017 at 02:13:00PM -0700, David Rientjes wrote:
> On Tue, 10 Oct 2017, Roman Gushchin wrote:
>
> > > This seems to unfairly bias the root mem cgroup depending on process
> > > size.
> > > It isn't treated fairly as a leaf mem cgroup if they are being compared
> > > based on dif
On Tue, 10 Oct 2017, Roman Gushchin wrote:
> > This seems to unfairly bias the root mem cgroup depending on process size.
> > It isn't treated fairly as a leaf mem cgroup if they are being compared
> > based on different criteria: the root mem cgroup as (mostly) the largest
> > rss of a single
On Mon, Oct 09, 2017 at 02:52:53PM -0700, David Rientjes wrote:
> On Thu, 5 Oct 2017, Roman Gushchin wrote:
>
> > Traditionally, the OOM killer is operating on a process level.
> > Under oom conditions, it finds a process with the highest oom score
> > and kills it.
> >
> > This behavior doesn't
On Mon 09-10-17 14:52:53, David Rientjes wrote:
> On Thu, 5 Oct 2017, Roman Gushchin wrote:
>
> > Traditionally, the OOM killer is operating on a process level.
> > Under oom conditions, it finds a process with the highest oom score
> > and kills it.
> >
> > This behavior doesn't suit well the sy
On Thu, 5 Oct 2017, Roman Gushchin wrote:
> Traditionally, the OOM killer is operating on a process level.
> Under oom conditions, it finds a process with the highest oom score
> and kills it.
>
> This behavior doesn't suit well the system with many running
> containers:
>
> 1) There is no fairn
On Thu 05-10-17 14:04:51, Roman Gushchin wrote:
> Traditionally, the OOM killer is operating on a process level.
> Under oom conditions, it finds a process with the highest oom score
> and kills it.
>
> This behavior doesn't suit well the system with many running
> containers:
>
> 1) There is no
Traditionally, the OOM killer is operating on a process level.
Under oom conditions, it finds a process with the highest oom score
and kills it.
This behavior doesn't suit well the system with many running
containers:
1) There is no fairness between containers. A small container with
few large pr
16 matches
Mail list logo