Re: [Fwd: [-mm] Add an owner to the mm_struct (v9)]

[Balbir Singh]

Hi, Oleg,

I've been slow in responding and I expect that situation to continue till the
weekend. I hope to respond to your queries sooner

Oleg Nesterov wrote:
> On 04/17, Paul Menage wrote:
>> On Thu, Apr 17, 2008 at 4:30 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>>>  >
>>>  > I had this loop earlier (inspired from zap_threads()), is this loop more
>>>  > efficient than what we have?
>>>
>>>  All sub-threads have the same ->mm. Once we see that c->mm != mm, we don't
>>>  need to waste CPU iterating over the all other threads in the thread group.
>> Technically they don't have to have the same mm, right? You can use
>> CLONE_THREAD without CLONE_VM when creating a new subthread.
> 
> No, no, this is not possible/allowed.
> 
> Please look at copy_process, CLONE_THREAD requires CLONE_SIGHAND,
> CLONE_SIGHAND needs CLONE_VM.
> 

What about the other way round, CLONE_VM without CLONE_THREAD?


>>>  chance you have the "for dummies" explanation what mm->owner is?
>>>  I mean, I can't understand how it is possible that 2 CLONE_VM tasks
>>>  are not equal wrt "ownering".
>> The idea is to be able to get from an mm to a task, where that task is
>> representative of the tasks using the mm. Uses include:
> 
> Thanks! but...
> 
> Let's suppose 2 task belongs to different cgroups, but share ->mm,
> 
>> - swap cgroup - when swapping from an mm, find a task whose swap
>> cgroup we can charge the swap page to
> 
> now we will charge the somewhat "random" cgroup. The one to which
> the result of the last "find the next suitable owner" belongs.
> 

Basically, with mm->owner and prior to that with the memory controller, we group
tasks by mm_struct instead of by task (virtually). Earlier, we had a hook in
mm_struct to tell us where the mm_struct belonged (to which cgroup). With
mm->owner, we can figure out where each subsystem belongs without having hooks
in mm_struct for each memory based controller subsystem.

When the owner exits (mm->owner), we pick the next owner and tell the tasks via
notification that the cgroup has changed (if it does). This does bring about
some issues, where without control accounting can move to a different cgroup all
of a sudden. To avoid that

We would recommend that the memory based controllers be mounted separately and
all related threads be put in the same cgroup


> This looks a bit strange to me... but OK, as I said, I don't know
> what cgroup is, please ignore me ;)
> 
> Oleg.
> 

Thanks for your review!

-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
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/