On Wed, 23 Aug 2017, Roman Gushchin wrote:
> > It's better to have newbies consult the documentation once than making
> > everybody deal with long and cumbersome names for the rest of time.
> >
> > Like 'ls' being better than 'read_and_print_directory_contents'.
>
> I don't think it's a good
On Wed, Aug 23, 2017 at 01:24:41PM -0400, Johannes Weiner wrote:
> Hi,
>
> On Wed, Aug 23, 2017 at 05:20:31PM +0100, Roman Gushchin wrote:
> > On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote:
> > > > + css_task_iter_start(>css, 0, );
> > > > + while ((task =
Hi,
On Wed, Aug 23, 2017 at 05:20:31PM +0100, Roman Gushchin wrote:
> On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote:
> > > + css_task_iter_start(>css, 0, );
> > > + while ((task = css_task_iter_next())) {
> > > + /*
> > > + * If there are no tasks, or all tasks
Hi Johannes!
Thank you for review!
I do agree with most of the comments, and I will address them in v6.
I'll post it soon.
Please, find some comments below.
On Tue, Aug 22, 2017 at 01:03:44PM -0400, Johannes Weiner wrote:
> Hi Roman,
>
> great work! This looks mostly good to me now. Below are
Hi Roman,
great work! This looks mostly good to me now. Below are some nitpicks
concerning naming and code layout, but nothing major.
On Mon, Aug 14, 2017 at 07:32:11PM +0100, Roman Gushchin wrote:
> @@ -39,6 +39,7 @@ struct oom_control {
> unsigned long totalpages;
> struct
On Wed, 16 Aug 2017, Roman Gushchin wrote:
> It's natural to expect that inside a container there are their own sshd,
> "activity manager" or some other stuff, which can play with oom_score_adj.
> If it can override the upper cgroup-level settings, the whole delegation model
> is broken.
>
I
On Tue, Aug 15, 2017 at 02:47:10PM -0700, David Rientjes wrote:
> On Tue, 15 Aug 2017, Roman Gushchin wrote:
>
> > > I'm curious about the decision made in this conditional and how
> > > oom_kill_memcg_member() ignores task->signal->oom_score_adj. It means
> > > that memory.oom_kill_all_tasks
On Tue, 15 Aug 2017, Roman Gushchin wrote:
> > I'm curious about the decision made in this conditional and how
> > oom_kill_memcg_member() ignores task->signal->oom_score_adj. It means
> > that memory.oom_kill_all_tasks overrides /proc/pid/oom_score_adj if it
> > should otherwise be disabled.
On Tue, Aug 15, 2017 at 10:20:18PM +1000, Aleksa Sarai wrote:
> On 08/15/2017 10:15 PM, Roman Gushchin wrote:
> > Generally, oom_score_adj should have a meaning only on a cgroup level,
> > so extending it to the system level doesn't sound as a good idea.
>
> But wasn't the original purpose of
On 08/15/2017 10:15 PM, Roman Gushchin wrote:
Generally, oom_score_adj should have a meaning only on a cgroup level,
so extending it to the system level doesn't sound as a good idea.
But wasn't the original purpose of oom_score (and oom_score_adj) to work
on a system level, aka "normal" OOM?
On Mon, Aug 14, 2017 at 03:42:54PM -0700, David Rientjes wrote:
> On Mon, 14 Aug 2017, Roman Gushchin wrote:
> > +
> > +static long oom_evaluate_memcg(struct mem_cgroup *memcg,
> > + const nodemask_t *nodemask)
> > +{
> > + struct css_task_iter it;
> > + struct
On Mon, 14 Aug 2017, Roman Gushchin wrote:
> diff --git a/include/linux/oom.h b/include/linux/oom.h
> index 8a266e2be5a6..b7ec3bd441be 100644
> --- a/include/linux/oom.h
> +++ b/include/linux/oom.h
> @@ -39,6 +39,7 @@ struct oom_control {
> unsigned long totalpages;
> struct
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
13 matches
Mail list logo
