Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

y) irrespective of the presence of swap". On Thu, Dec 21, 2017 at 9:29 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, Shakeel. > > On Thu, Dec 21, 2017 at 07:22:20AM -0800, Shakeel Butt wrote: >> I am claiming memory allocations under global pressure will be >> aff

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Thu, Dec 21, 2017 at 5:37 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, Shakeel. > > On Wed, Dec 20, 2017 at 05:15:41PM -0800, Shakeel Butt wrote: >> Let's say we have a job that allocates 100 MiB memory and suppose 80 >> MiB is anon and 20 MiB is non-anon (file

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Wed, Dec 20, 2017 at 3:36 PM, Tejun Heo <t...@kernel.org> wrote: > Hello, Shakeel. > > On Wed, Dec 20, 2017 at 12:15:46PM -0800, Shakeel Butt wrote: >> > I don't understand how this invariant is useful across different >> > backing swap devices and avai

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Wed, Dec 20, 2017 at 11:37 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, Shakeel. > > On Tue, Dec 19, 2017 at 02:39:19PM -0800, Shakeel Butt wrote: >> Suppose a user wants to run multiple instances of a specific job on >> different datacenters and s/he has budget

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Tue, Dec 19, 2017 at 1:41 PM, Tejun Heo <t...@kernel.org> wrote: > Hello, > > On Tue, Dec 19, 2017 at 10:25:12AM -0800, Shakeel Butt wrote: >> Making the runtime environment, an invariant is very critical to make >> the management of a job easier whose instances r

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Tue, Dec 19, 2017 at 9:33 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, > > On Tue, Dec 19, 2017 at 09:23:29AM -0800, Shakeel Butt wrote: >> To provide consistent memory usage history using the current >> cgroup-v2's 'swap' interface, an additional metric exp

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Tue, Dec 19, 2017 at 7:24 AM, Tejun Heo <t...@kernel.org> wrote: > Hello, > > On Tue, Dec 19, 2017 at 07:12:19AM -0800, Shakeel Butt wrote: >> Yes, there are pros & cons, therefore we should give users the option >> to select the API that is better suited for thei

Re: [RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

On Tue, Dec 19, 2017 at 4:49 AM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 18-12-17 16:01:31, Shakeel Butt wrote: >> The memory controller in cgroup v1 provides the memory+swap (memsw) >> interface to account to the combined usage of memory and swap of the >>

[RFC PATCH] mm: memcontrol: memory+swap accounting for cgroup-v2

if there are no decendants of the root cgroup. When memsw accounting is enabled then "memory.high" is comapred with memory+swap usage. So, when the allocating job's memsw usage hits its high mark, the job will be throttled by triggering memory reclaim. Signed-off-by: Shakeel Butt <shake.

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

On Tue, Oct 31, 2017 at 9:40 AM, Johannes Weiner <han...@cmpxchg.org> wrote: > On Tue, Oct 31, 2017 at 08:04:19AM -0700, Shakeel Butt wrote: >> > + >> > +static void select_victim_memcg(struct mem_cgroup *root, struct >> > oom_control *oc) >>

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

> + > +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control > *oc) > +{ > + struct mem_cgroup *iter; > + > + oc->chosen_memcg = NULL; > + oc->chosen_points = 0; > + > + /* > +* The oom_score is calculated for leaf memory cgroups (including >

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

>> > + 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. Thanks! > > This should fix the problem. > -- > diff --git a/mm/memcontrol.c

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

> + > +static void select_victim_memcg(struct mem_cgroup *root, struct oom_control > *oc) > +{ > + struct mem_cgroup *iter; > + > + oc->chosen_memcg = NULL; > + oc->chosen_points = 0; > + > + /* > +* The oom_score is calculated for leaf memory cgroups (including >

Re: [v8 0/4] cgroup-aware OOM killer

On Mon, Oct 2, 2017 at 12:56 PM, Michal Hocko <mho...@kernel.org> wrote: > On Mon 02-10-17 12:45:18, Shakeel Butt wrote: >> > I am sorry to cut the rest of your proposal because it simply goes over >> > the scope of the proposed solution while the usecase you are mentio

Re: [v8 0/4] cgroup-aware OOM killer

> I am sorry to cut the rest of your proposal because it simply goes over > the scope of the proposed solution while the usecase you are mentioning > is still possible. If we want to compare intermediate nodes (which seems > to be the case) then we can always provide a knob to opt-in - be it your

Re: [v8 0/4] cgroup-aware OOM killer

> 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

Re: [v8 0/4] cgroup-aware OOM killer

> > 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

Re: [v7 5/5] mm, oom: cgroup v2 mount option to disable cgroup-aware OOM killer

On Mon, Sep 4, 2017 at 7:21 AM, Roman Gushchin wrote: > Introducing of cgroup-aware OOM killer changes the victim selection > algorithm used by default: instead of picking the largest process, > it will pick the largest memcg and then the largest process inside. > > This affects only