Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu 05-10-17 15:02:18, David Rientjes wrote: [...] > I would need to add patches to add the "evaluate as a whole but do not > kill all" knob and a knob for "oom priority" so that userspace has the > same influence over a cgroup based comparison that it does with a process > based comparison

[PATCH] PM: docs: Fix stale reference in kernel-parameters.txt

From: Rafael J. Wysocki Commit 7aa7a0360a66 (PM: docs: Delete the obsolete states.txt document) forgot to update kernel-parameters.txt with a reference to the new sleep-states.rst document and it still points to states.txt that was dropped, so fix it now. Fixes:

Re: [PATCH 3/4] dt-bindings: hwmon: Add max-expected-current property to ina2xx

On Thu, Oct 05, 2017 at 05:15:07PM +0200, Maciej Purski wrote: > On 10/01/2017 12:31 PM, Jonathan Cameron wrote: > > On Thu, 28 Sep 2017 14:50:14 +0200 > > Maciej Purski wrote: > > > > > Add optional max expected current property which allows calibrating > > > the ina

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu, 5 Oct 2017, Roman Gushchin wrote: > > This patchset exists because overcommit is real, exactly the same as > > overcommit within memcg hierarchies is real. 99% of the time we don't run > > into global oom because people aren't using their limits so it just works > > out. 1% of the

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu, 5 Oct 2017, Johannes Weiner wrote: > > It is, because it can quite clearly be a DoSand was prevented with > > Roman's earlier design of iterating usage up the hierarchy and comparing > > siblings based on that criteria. I know exactly why he chose that > > implementation detail early

Re: [RFC PATCH 1/2] kbuild: Add a cache for generated variables

Hi, On Thu, Oct 5, 2017 at 12:26 AM, Masahiro Yamada wrote: > As far as I tested, I always see only one space after ":=" in v2. > > I did not consider this deeply, > but something is working nicely behind the scene. Try adding this to the end of the main Makefile:

Re: [PATCH] doc: Fix typo "8023.ad" in bonding documentation

Hi Jon, thanks for the prompt reply. On Thu, Oct 05, 2017 at 01:15:04PM -0600, Jonathan Corbet wrote: > On Thu, 5 Oct 2017 20:26:24 +0200 > Axel Beckert wrote: > > > Should be "802.3ad" like everywhere else in the document. > > Could you do me a favor, please, and submit

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

Em Thu, 5 Oct 2017 11:21:07 +0300 Sakari Ailus escreveu: > Hi Mauro, > > My apologies for the late reply. > > On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote: > > Em Tue, 29 Aug 2017 10:47:48 +0300 > > Sakari Ailus escreveu: > >

[PATCH] doc: Fix typo "8023.ad" in bonding documentation

Should be "802.3ad" like everywhere else in the document. Signed-off-by: Axel Beckert --- Documentation/networking/bonding.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

On Thu 05-10-17 10:54:01, Johannes Weiner wrote: > On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > > On Wed 04-10-17 16:04:53, Johannes Weiner wrote: > > [...] > > > That will silently ignore what the user writes to the memory.oom_group > > > control files across the system's

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

Hello, Michal. On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > Yes and that is why I think a boot time knob would be the most simple > way. It will also open doors for more oom policies in future which I > believe come sooner or later. While boot params are fine for development

Re: [PATCH 3/4] dt-bindings: hwmon: Add max-expected-current property to ina2xx

On 10/01/2017 12:31 PM, Jonathan Cameron wrote: On Thu, 28 Sep 2017 14:50:14 +0200 Maciej Purski wrote: Add optional max expected current property which allows calibrating the ina sensor in order to achieve requested precision. Document the changes in

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > On Wed 04-10-17 16:04:53, Johannes Weiner wrote: > [...] > > That will silently ignore what the user writes to the memory.oom_group > > control files across the system's cgroup tree. > > > > We'll have a knob that lets the workload

Re: [v11 4/6] mm, oom: introduce memory.oom_group

Btw. here is how I would do the recursive oom badness. The diff is not the nicest one because there is some code moving but the resulting code is smaller and imho easier to grasp. Only compile tested though --- diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index

Re: [v11 4/6] mm, oom: introduce memory.oom_group

On Thu 05-10-17 14:04:52, Roman Gushchin wrote: > The cgroup-aware OOM killer treats leaf memory cgroups as memory > consumption entities and performs the victim selection by comparing > them based on their memory footprint. Then it kills the biggest task > inside the selected memory cgroup. > >

Re: [v11 3/6] mm, oom: cgroup-aware OOM killer

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

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

On Thu 05-10-17 14:41:13, Roman Gushchin wrote: > On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > > On Wed 04-10-17 16:04:53, Johannes Weiner wrote: > > [...] > > > That will silently ignore what the user writes to the memory.oom_group > > > control files across the system's cgroup

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote: > On Wed 04-10-17 16:04:53, Johannes Weiner wrote: > [...] > > That will silently ignore what the user writes to the memory.oom_group > > control files across the system's cgroup tree. > > > > We'll have a knob that lets the workload

Re: [v10 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

On Wed 04-10-17 16:04:53, Johannes Weiner wrote: [...] > That will silently ignore what the user writes to the memory.oom_group > control files across the system's cgroup tree. > > We'll have a knob that lets the workload declare itself an indivisible > memory consumer, that it would like to get

[v11 0/6] cgroup-aware OOM killer

This patchset makes the OOM killer cgroup-aware. v11: - Fixed an issue with skipping the root mem cgroup (discovered by Shakeel Butt) - Moved a check in __oom_kill_process() to the memmory.oom_group patch, added corresponding comments - Added a note about ignoring tasks with

[v11 2/6] mm: implement mem_cgroup_scan_tasks() for the root memory cgroup

Implement mem_cgroup_scan_tasks() functionality for the root memory cgroup to use this function for looking for a OOM victim task in the root memory cgroup by the cgroup-ware OOM killer. The root memory cgroup is treated as a leaf cgroup, so only tasks which are directly belonging to the root

[v11 5/6] mm, oom: add cgroup v2 mount option for cgroup-aware OOM killer

Add a "groupoom" cgroup v2 mount option to enable the cgroup-aware OOM killer. If not set, the OOM selection is performed in a "traditional" per-process way. The behavior can be changed dynamically by remounting the cgroupfs. Signed-off-by: Roman Gushchin Cc: Michal Hocko

[v11 3/6] mm, oom: cgroup-aware OOM killer

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

[v11 4/6] mm, oom: introduce memory.oom_group

The cgroup-aware OOM killer treats leaf memory cgroups as memory consumption entities and performs the victim selection by comparing them based on their memory footprint. Then it kills the biggest task inside the selected memory cgroup. But there are workloads, which are not tolerant to a such

[v11 1/6] mm, oom: refactor the oom_kill_process() function

The oom_kill_process() function consists of two logical parts: the first one is responsible for considering task's children as a potential victim and printing the debug information. The second half is responsible for sending SIGKILL to all tasks sharing the mm struct with the given victim. This

Re: [v10 4/6] mm, oom: introduce memory.oom_group

On Thu 05-10-17 13:32:14, Roman Gushchin wrote: > On Thu, Oct 05, 2017 at 02:06:49PM +0200, Michal Hocko wrote: > > On Wed 04-10-17 16:46:36, Roman Gushchin wrote: > > > The cgroup-aware OOM killer treats leaf memory cgroups as memory > > > consumption entities and performs the victim selection by

Re: [v10 4/6] mm, oom: introduce memory.oom_group

On Thu, Oct 05, 2017 at 02:06:49PM +0200, Michal Hocko wrote: > On Wed 04-10-17 16:46:36, Roman Gushchin wrote: > > The cgroup-aware OOM killer treats leaf memory cgroups as memory > > consumption entities and performs the victim selection by comparing > > them based on their memory footprint.

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

Em Thu, 5 Oct 2017 11:21:07 +0300 Sakari Ailus escreveu: > Hi Mauro, > > My apologies for the late reply. > > On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote: > > Em Tue, 29 Aug 2017 10:47:48 +0300 > > Sakari Ailus escreveu: > >

Re: [v10 4/6] mm, oom: introduce memory.oom_group

On Wed 04-10-17 16:46:36, Roman Gushchin wrote: > The cgroup-aware OOM killer treats leaf memory cgroups as memory > consumption entities and performs the victim selection by comparing > them based on their memory footprint. Then it kills the biggest task > inside the selected memory cgroup. > >

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu, Oct 05, 2017 at 01:12:30PM +0200, Michal Hocko wrote: > On Thu 05-10-17 11:27:07, Roman Gushchin wrote: > > On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: > [...] > > > Sorry about the confusion. There are two things. First, should we do a > > > css_get on the newly selected

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Wed 04-10-17 16:46:35, 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

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Wed 04-10-17 16:31:38, Johannes Weiner wrote: > On Wed, Oct 04, 2017 at 01:17:14PM -0700, David Rientjes wrote: > > On Wed, 4 Oct 2017, Roman Gushchin wrote: > > > > > > > @@ -828,6 +828,12 @@ static void __oom_kill_process(struct > > > > > task_struct *victim) > > > > > struct

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu 05-10-17 11:27:07, Roman Gushchin wrote: > On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: [...] > > Sorry about the confusion. There are two things. First, should we do a > > css_get on the newly selected memcg within the for loop when we still > > have a reference to it? >

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu, Oct 05, 2017 at 01:40:09AM -0700, David Rientjes wrote: > On Wed, 4 Oct 2017, Johannes Weiner wrote: > > > > By only considering leaf memcgs, does this penalize users if their memcg > > > becomes oc->chosen_memcg purely because it has aggregated all of its > > > processes to be members

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Wed, Oct 04, 2017 at 02:24:26PM -0700, Shakeel Butt wrote: > >> > + if (memcg_has_children(iter)) > >> > + continue; > >> > >> && iter != root_mem_cgroup ? > > > > Oh, sure. I had a stupid bug in my test script, which prevented me from > > catching this.

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Thu, Oct 05, 2017 at 01:40:09AM -0700, David Rientjes wrote: > On Wed, 4 Oct 2017, Johannes Weiner wrote: > > > > By only considering leaf memcgs, does this penalize users if their memcg > > > becomes oc->chosen_memcg purely because it has aggregated all of its > > > processes to be members

Re: [v10 3/6] mm, oom: cgroup-aware OOM killer

On Wed, 4 Oct 2017, Johannes Weiner wrote: > > By only considering leaf memcgs, does this penalize users if their memcg > > becomes oc->chosen_memcg purely because it has aggregated all of its > > processes to be members of that memcg, which would otherwise be the > > standard behavior? > > >

Re: [PATCH v5 1/7] media: add glossary.rst with a glossary of terms used at V4L2 spec

Hi Mauro, My apologies for the late reply. On Tue, Aug 29, 2017 at 10:07:50AM -0300, Mauro Carvalho Chehab wrote: > Em Tue, 29 Aug 2017 10:47:48 +0300 > Sakari Ailus escreveu: > > > Hi Mauro, > > > > Thanks for the update. A few comments below. > > > > On Mon, Aug 28,

Re: [PATCH v2 0/2] kbuild: Cache exploratory calls to the compiler

* Douglas Anderson wrote: > This two-patch series attempts to speed incremental builds of the > kernel up by a bit. How much of a speedup you get depends a lot on > your environment, specifically the speed of your workstation and how > fast it takes to invoke the

Re: [RFC PATCH 1/2] kbuild: Add a cache for generated variables

Hi Douglas, 2017-10-05 7:38 GMT+09:00 Doug Anderson : > Hi, > > On Tue, Oct 3, 2017 at 9:05 PM, Masahiro Yamada > wrote: >> Thanks for the patches. The idea is interesting. >> >> I am not a Chrome developer, but cc-option could be improved