Recently Kiril Tkhai reported that mm_update_next_ownerwas executing
it's expensive for_each_process fallback. Reading the code reveals
that all that is needed to trigger this is a multi-threaded process
where the thread group leader exits. AKA something anyone can easily
trigger an any time.
On 05/09, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> >> The patch does solve the issue. There should be nothing a userspace
> >> process can observe that should tell it where in the middle of exec
> >> such a migration happend so placing the migration at what from the
> >> kernel's pe
Oleg Nesterov writes:
> On 05/07, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > before your patch get_mem_cgroup_from_mm() looks at mm->owner == current
>> > (in this case) and mem_cgroup_from_task() should return the correct memcg
>> > even if execing task migrates after bprm_mm_
On Mon 07-05-18 16:18:01, Andrew Morton wrote:
> On Sun, 6 May 2018 00:54:48 +0800 kbuild test robot wrote:
>
> > Hi Eric,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on linus/master]
> > [also build test ERROR on v4.17-rc3]
> > [cannot apply to nex
On 05/07, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > before your patch get_mem_cgroup_from_mm() looks at mm->owner == current
> > (in this case) and mem_cgroup_from_task() should return the correct memcg
> > even if execing task migrates after bprm_mm_init(). At least in the common
>
Oleg Nesterov writes:
> On 05/04, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > On 05/04, Eric W. Biederman wrote:
>> >>
>> >> Oleg Nesterov writes:
>> >>
>> >> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can
>> >> > just
>> >> > nullify mm->memcg.
>> >>
>
Andrew Morton writes:
> On Sun, 6 May 2018 00:54:48 +0800 kbuild test robot wrote:
>
>> Hi Eric,
>>
>> Thank you for the patch! Yet something to improve:
>>
>> [auto build test ERROR on linus/master]
>> [also build test ERROR on v4.17-rc3]
>> [cannot apply to next-20180504]
>> [if your patch i
On Sun, 6 May 2018 00:54:48 +0800 kbuild test robot wrote:
> Hi Eric,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.17-rc3]
> [cannot apply to next-20180504]
> [if your patch is applied to the wrong git tree, pl
On 05/04, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > On 05/04, Eric W. Biederman wrote:
> >>
> >> Oleg Nesterov writes:
> >>
> >> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just
> >> > nullify mm->memcg.
> >>
> >> There is at least one common path where w
Hi Eric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc3]
[cannot apply to next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Oleg Nesterov writes:
> On 05/04, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just
>> > nullify mm->memcg.
>>
>> There is at least one common path where we need the memory control group
>> properly initialized
On 05/04, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just
> > nullify mm->memcg.
>
> There is at least one common path where we need the memory control group
> properly initialized so memory allocations don't escape
Oleg Nesterov writes:
> On 05/04, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early
>> > in
>> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ?
>>
>> We need the the cgroup when the mm i
On 05/04, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early in
> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ?
>
> We need the the cgroup when the mm is initialized. That way we have the
>
Oleg Nesterov writes:
> On 05/03, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > On 05/02, Eric W. Biederman wrote:
>> >>
>> >> +static void mem_cgroup_fork(struct task_struct *tsk)
>> >> +{
>> >> + struct cgroup_subsys_state *css;
>> >> +
>> >> + rcu_read_lock();
>> >> + css = tas
On 05/03, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > On 05/02, Eric W. Biederman wrote:
> >>
> >> +static void mem_cgroup_fork(struct task_struct *tsk)
> >> +{
> >> + struct cgroup_subsys_state *css;
> >> +
> >> + rcu_read_lock();
> >> + css = task_css(tsk, memory_cgrp_id);
> >> +
I am getting the following for nommu with MEMCG=y randconfig:
kernel/fork.o: In function `mm_init':
fork.c:(.text+0x948): undefined reference to `mm_update_memcg'
kernel/fork.o: In function `mmput':
fork.c:(.text+0x119c): undefined reference to `mm_update_memcg'
make: *** [vmlinux] Error 1
I am so
On Fri, May 4, 2018 at 1:11 AM, Eric W. Biederman wrote:
> Balbir Singh writes:
>
>> On Tue, 01 May 2018 12:35:16 -0500
>> ebied...@xmission.com (Eric W. Biederman) wrote:
>>
>>> Recently it was reported that mm_update_next_owner could get into
>>> cases where it was executing it's fallback for_e
Balbir Singh writes:
> On Tue, 01 May 2018 12:35:16 -0500
> ebied...@xmission.com (Eric W. Biederman) wrote:
>
>> Recently it was reported that mm_update_next_owner could get into
>> cases where it was executing it's fallback for_each_process part of
>> the loop and thus taking up a lot of time.
Oleg Nesterov writes:
> On 05/02, Eric W. Biederman wrote:
>>
>> +static void mem_cgroup_fork(struct task_struct *tsk)
>> +{
>> +struct cgroup_subsys_state *css;
>> +
>> +rcu_read_lock();
>> +css = task_css(tsk, memory_cgrp_id);
>> +if (css && css_tryget(css))
>> +task
On 05/02, Eric W. Biederman wrote:
>
> +static void mem_cgroup_fork(struct task_struct *tsk)
> +{
> + struct cgroup_subsys_state *css;
> +
> + rcu_read_lock();
> + css = task_css(tsk, memory_cgrp_id);
> + if (css && css_tryget(css))
> + task_update_memcg(tsk, mem_cgroup_
On Tue, 01 May 2018 12:35:16 -0500
ebied...@xmission.com (Eric W. Biederman) wrote:
> Recently it was reported that mm_update_next_owner could get into
> cases where it was executing it's fallback for_each_process part of
> the loop and thus taking up a lot of time.
>
> To deal with this replace
Andrew Morton writes:
> On Wed, 02 May 2018 14:21:35 -0500 ebied...@xmission.com (Eric W. Biederman)
> wrote:
>
>> Recently it was reported that mm_update_next_owner could get into
>> cases where it was executing it's fallback for_each_process part of
>> the loop and thus taking up a lot of time
On Wed, 02 May 2018 14:21:35 -0500 ebied...@xmission.com (Eric W. Biederman)
wrote:
> Recently it was reported that mm_update_next_owner could get into
> cases where it was executing it's fallback for_each_process part of
> the loop and thus taking up a lot of time.
>
> To deal with this replace
Recently it was reported that mm_update_next_owner could get into
cases where it was executing it's fallback for_each_process part of
the loop and thus taking up a lot of time.
To deal with this replace mm->owner with mm->memcg. This just reduces
the complexity of everything. As much as possibl
Johannes Weiner writes:
> Hi Eric,
>
> On Wed, May 02, 2018 at 10:47:08AM +0200, Michal Hocko wrote:
>> [CC johannes and Tejun as well. I am sorry but my backlog is so huge I
>> will not get to this week.]
>>
>> On Tue 01-05-18 12:35:16, Eric W. Biederman wrote:
>> > Recently it was reported tha
Hi Eric,
On Wed, May 02, 2018 at 10:47:08AM +0200, Michal Hocko wrote:
> [CC johannes and Tejun as well. I am sorry but my backlog is so huge I
> will not get to this week.]
>
> On Tue 01-05-18 12:35:16, Eric W. Biederman wrote:
> > Recently it was reported that mm_update_next_owner could get int
[CC johannes and Tejun as well. I am sorry but my backlog is so huge I
will not get to this week.]
On Tue 01-05-18 12:35:16, Eric W. Biederman wrote:
> Recently it was reported that mm_update_next_owner could get into
> cases where it was executing it's fallback for_each_process part of
> the loop
Recently it was reported that mm_update_next_owner could get into
cases where it was executing it's fallback for_each_process part of
the loop and thus taking up a lot of time.
To deal with this replace mm->owner with mm->memcg. This just reduces
the complexity of everything. As much as possibl
29 matches
Mail list logo
