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 t
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: 7aa7a0360a66 (PM: docs: Delete th
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 sensor in order to achieve r
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 tim
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 o
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:
+$(info LDFLAGS_BUILD_ID = $(L
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 this one to Dave Mille
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 this one to Dave Miller and
netdev? He prefers to handle networking docs patches himself.
Thanks,
jon
--
To unsubscribe from this list:
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:
> >
> > > Hi Mauro,
> > >
> > > Thanks for
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
index 57f52cdce32e..9ba0
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 cgroup
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 an
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 Documentation/hwmon/ina2xx.
This is int
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 de
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 085056e562b1..9cdba46
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.
>
> B
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
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
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 de
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 k
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 oom_scor
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 cgro
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
Cc: Vladimir Davydov
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
Document the cgroup-aware OOM killer.
Signed-off-by: Roman Gushchin
Cc: Michal Hocko
Cc: Vladimir Davydov
Cc: Johannes Weiner
Cc: Tetsuo Handa
Cc: Andrew Morton
Cc: David Rientjes
Cc: Tejun Heo
Cc: kernel-t...@fb.com
Cc: cgro...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-ker..
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 beh
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 co
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
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. Then
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:
> >
> > > Hi Mauro,
> > >
> > > Thanks for
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.
>
> B
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
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
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 mm_struct
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?
>
>
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 o
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. Thank
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 o
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?
> >
>
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, 2017 at 09:53:55AM -0300
* 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 compiler.
>
> In the Chrome OS
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 somehow.
>>
>>
>> I examined two approaches to mitigate
42 matches
Mail list logo
