[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87efj2q6sq.fsf@xmission.com>
Date: Thu, 26 Apr 2018 11:19:33 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Michal Hocko <mhocko@...nel.org>
Cc: Kirill Tkhai <ktkhai@...tuozzo.com>, akpm@...ux-foundation.org,
peterz@...radead.org, oleg@...hat.com, viro@...iv.linux.org.uk,
mingo@...nel.org, paulmck@...ux.vnet.ibm.com,
keescook@...omium.org, riel@...hat.com, tglx@...utronix.de,
kirill.shutemov@...ux.intel.com, marcos.souza.org@...il.com,
hoeun.ryu@...il.com, pasha.tatashin@...cle.com, gs051095@...il.com,
dhowells@...hat.com, rppt@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable
Michal Hocko <mhocko@...nel.org> writes:
> I've had a patch to remove owner few years back. It needed some work
> to finish but maybe that would be a better than try to make
> non-scalable thing suck less.
I have a question. Would it be reasonable to just have a mm->memcg?
That would appear to be the simplest solution to the problem.
That would require failing migration between memory cgroups if you are
not moving all of processes/threads that have a given mm_struct. That
should not be a huge restriction as typically it is only threads that
share a mm. Further the check should be straigh forward: counting the
number of threads and verifying the count matches the count on the
mm_struct.
Eric
Powered by blists - more mailing lists