Re: [RFC 3/3] memcg: get rid of mm_struct::owner

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri 29-05-15 09:10:55, Tejun Heo wrote:
> On Fri, May 29, 2015 at 02:08:38PM +0200, Michal Hocko wrote:
> > > I suppose that making mm always follow the threadgroup leader should
> > > be fine, right? 
> > 
> > That is the plan.
> 
> Cool.
> 
> > > While this wouldn't make any difference in the unified hierarchy,
> > 
> > Just to make sure I understand. "wouldn't make any difference" because
> > the API is not backward compatible right?
> 
> Hmm... because it's always per-process.  If any thread is going, the
> whole process is going together.

Sure but we are talking about processes here. They just happen to share
mm. And this is exactly the behavior change I am talking about... With
the owner you could emulate "threads" with this patch you cannot
anymore. IMO we shouldn't allow for that but just reading the original
commit message (cf475ad28ac35) which has added mm->owner:
"
It also allows several control groups that are virtually grouped by
mm_struct, to exist independent of the memory controller i.e., without
adding mem_cgroup's for each controller, to mm_struct.
"
suggests it might have been intentional. That being said, I think it was
a mistake back at the time and we should move on to a saner model. But I
also believe we should be really vocal when the user visible behavior
changes. If somebody really asks for the previous behavior I would
insist on a _strong_ usecase.
-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]