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

[Michal Hocko]

On Fri 29-05-15 10:07:37, Tejun Heo wrote:
> Hello,
> 
> On Fri, May 29, 2015 at 03:45:53PM +0200, Michal Hocko wrote:
> > 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
> 
> Are we talking about CLONE_VM w/o CLONE_THREAD?  ie. two threadgroups
> sharing the same VM?

yes.

> > 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
> 
> I think he's talking about implmenting different controllers which may
> want to add their own css pointer in mm_struct now wouldn't need to as
> the mm is tagged with the owning task from which membership of all
> controllers can be derived.  I don't think that's something we need to
> worry about.  We haven't seen even a suggestion for such a controller
> and even if that happens we'd be better off adding a separate field
> for the new controller.

Maybe I've just misunderstood. My understandig was that tasks sharing
the mm could live in different cgroups while the memory would be bound
by a shared memcg.

> > 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.
> 
> I'm a bit lost on what's cleared defined is actually changing.  It's
> not like userland had firm control over mm->owner.  It was already a
> crapshoot, no?

OK so you creat a task A (leader) which clones several tasks Pn with
CLONE_VM without CLONE_THREAD. Moving A around would control memcg
membership while Pn could be moved around freely to control membership
in other controllers (e.g. cpu to control shares). So it is something
like moving threads separately.
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/