I think Tim has given very clear explanation why comparing A & D makes perfect sense. However I think the above example, a single user system
where a user has designed and created the whole hierarchy and then
attaches different jobs/applications to different nodes in this
hierarchy, is also a valid scenario. One solution I can think of, to
cater both scenarios, is to introduce a notion of 'bypass oom' or not
include a memcg for oom comparision and instead include its children
in the comparison.
Going back to Michal's example, say the user configured the following:
root
/ \
A D
/ \
B C
A global OOM event happens and we find this:
- A > D
- B, C, D are oomgroups
What the user is telling us is that B, C, and D are compound memory consumers. They cannot be divided into their task parts from a memory
point of view.
However, the user doesn't say the same for A: the A subtree summarizes
and controls aggregate consumption of B and C, but without groupoom
set on A, the user says that A is in fact divisible into independent
memory consumers B and C.
If we don't have to kill all of A, but we'd have to kill all of D,
does it make sense to compare the two?
I think Tim has given very clear explanation why comparing A & D makes perfect sense. However I think the above example, a single user system
where a user has designed and created the whole hierarchy and then
attaches different jobs/applications to different nodes in this
hierarchy, is also a valid scenario.
Yes and nobody is disputing that, really. I guess the main disconnect
here is that different people want to have more detailed control over
the victim selection while the patchset tries to handle the most
simplistic scenario when a no userspace control over the selection is required. And I would claim that this will be a last majority of setups
and we should address it first.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 293 |
Nodes: | 16 (2 / 14) |
Uptime: | 211:17:58 |
Calls: | 6,619 |
Calls today: | 1 |
Files: | 12,168 |
Messages: | 5,317,308 |