On Fri, Aug 21, 2020 at 11:53 AM Suren Baghdasaryan wrote:
>
> On Fri, Aug 21, 2020 at 11:00 AM Oleg Nesterov wrote:
> >
> > On 08/21, Oleg Nesterov wrote:
> > >
> > > On 08/21, Suren Baghdasaryan wrote:
> > > >
> > > > On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
> > > > >
> > > > >
On Fri, Aug 21, 2020 at 11:00 AM Oleg Nesterov wrote:
>
> On 08/21, Oleg Nesterov wrote:
> >
> > On 08/21, Suren Baghdasaryan wrote:
> > >
> > > On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
> > > >
> > > > bool probably_has_other_mm_users(tsk)
> > > > {
> > > >
On 08/21, Oleg Nesterov wrote:
>
> On 08/21, Suren Baghdasaryan wrote:
> >
> > On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
> > >
> > > bool probably_has_other_mm_users(tsk)
> > > {
> > > return atomic_read_acquire(&tsk->mm->mm_users) >
> > >
On Fri, Aug 21, 2020 at 9:37 AM Oleg Nesterov wrote:
>
> again, don't really understand...
>
> On 08/21, Suren Baghdasaryan wrote:
> >
> > Actually, reviewing again and considering where list_add_tail_rcu is
> > happening, maybe the race with clone(CLONE_VM) does not introduce
> > false negatives.
again, don't really understand...
On 08/21, Suren Baghdasaryan wrote:
>
> Actually, reviewing again and considering where list_add_tail_rcu is
> happening, maybe the race with clone(CLONE_VM) does not introduce
> false negatives.
I think it does... Whatever we check, mm_users or MMF_PROC_SHARED,
On 08/21, Suren Baghdasaryan wrote:
>
> On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
> >
> > bool probably_has_other_mm_users(tsk)
> > {
> > return atomic_read_acquire(&tsk->mm->mm_users) >
> > atomic_read(&tsk->signal->live);
> >
On Fri, Aug 21, 2020 at 8:28 AM Suren Baghdasaryan wrote:
>
> On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
> >
> > On 08/20, Eric W. Biederman wrote:
> > >
> > > That said if we are going for a small change why not:
> > >
> > > /*
> > >* Make sure we will check other process
On Fri, Aug 21, 2020 at 4:16 AM Oleg Nesterov wrote:
>
> On 08/20, Eric W. Biederman wrote:
> >
> > That said if we are going for a small change why not:
> >
> > /*
> >* Make sure we will check other processes sharing the mm if this is
> >* not vfrok which wants its own oom_s
On 08/20, Eric W. Biederman wrote:
>
> That said if we are going for a small change why not:
>
> /*
>* Make sure we will check other processes sharing the mm if this is
>* not vfrok which wants its own oom_score_adj.
>* pin the mm so it doesn't go away and get reused a
On Thu 20-08-20 23:39:25, Eric W. Biederman wrote:
> Michal Hocko writes:
>
> > On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote:
> > [...]
> >> Catching up on the discussion which was going on while I was asleep...
> >> So it sounds like there is a consensus that oom_adj should be moved to
> >
Michal Hocko writes:
> On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote:
> [...]
>> Catching up on the discussion which was going on while I was asleep...
>> So it sounds like there is a consensus that oom_adj should be moved to
>> mm_struct rather than trying to synchronize it among tasks shar
On Thu, Aug 20, 2020 at 9:29 AM Christian Brauner
wrote:
>
> On Thu, Aug 20, 2020 at 06:26:45PM +0200, Michal Hocko wrote:
> > On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote:
> > [...]
> > > Catching up on the discussion which was going on while I was asleep...
> > > So it sounds like there is
On Thu, Aug 20, 2020 at 06:26:45PM +0200, Michal Hocko wrote:
> On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote:
> [...]
> > Catching up on the discussion which was going on while I was asleep...
> > So it sounds like there is a consensus that oom_adj should be moved to
> > mm_struct rather than
On Thu 20-08-20 08:56:53, Suren Baghdasaryan wrote:
[...]
> Catching up on the discussion which was going on while I was asleep...
> So it sounds like there is a consensus that oom_adj should be moved to
> mm_struct rather than trying to synchronize it among tasks sharing mm.
> That sounds reasonab
On Thu, Aug 20, 2020 at 7:53 AM Eric W. Biederman wrote:
>
> Tetsuo Handa writes:
>
> > On 2020/08/20 23:00, Christian Brauner wrote:
> >> On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
> >>> On 2020/08/20 22:34, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 03:26:31PM +0
Oleg Nesterov writes:
> On 08/20, Oleg Nesterov wrote:
>>
>> On 08/20, Eric W. Biederman wrote:
>> >
>> > --- a/fs/exec.c
>> > +++ b/fs/exec.c
>> > @@ -1139,6 +1139,10 @@ static int exec_mmap(struct mm_struct *mm)
>> >vmacache_flush(tsk);
>> >task_unlock(tsk);
>> >if (old_mm) {
>> > +
On Thu, Aug 20, 2020 at 09:49:11AM -0500, Eric W. Biederman wrote:
> Tetsuo Handa writes:
>
> > On 2020/08/20 23:00, Christian Brauner wrote:
> >> On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
> >>> On 2020/08/20 22:34, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 03:26
Tetsuo Handa writes:
> On 2020/08/20 23:00, Christian Brauner wrote:
>> On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
>>> On 2020/08/20 22:34, Christian Brauner wrote:
On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
> If you can handle vfork by other means t
Oleg Nesterov writes:
> On 08/20, Eric W. Biederman wrote:
>>
>> --- a/fs/exec.c
>> +++ b/fs/exec.c
>> @@ -1139,6 +1139,10 @@ static int exec_mmap(struct mm_struct *mm)
>> vmacache_flush(tsk);
>> task_unlock(tsk);
>> if (old_mm) {
>> +mm->oom_score_adj = old_mm->oom_sco
On 08/20, Oleg Nesterov wrote:
>
> On 08/20, Eric W. Biederman wrote:
> >
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -1139,6 +1139,10 @@ static int exec_mmap(struct mm_struct *mm)
> > vmacache_flush(tsk);
> > task_unlock(tsk);
> > if (old_mm) {
> > + mm->oom_score_adj = ol
On Thu 20-08-20 23:26:29, Tetsuo Handa wrote:
> On 2020/08/20 23:15, Michal Hocko wrote:
> > I would tend to agree that from the userspace POV it is nice to look at
> > oom tuning per process but fundamentaly the oom killer operates on the
> > address space much more than other resources bound to a
On 2020/08/20 23:15, Michal Hocko wrote:
> I would tend to agree that from the userspace POV it is nice to look at
> oom tuning per process but fundamentaly the oom killer operates on the
> address space much more than other resources bound to a process because
> it is usually the address space hog
On 2020/08/20 23:00, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
>> On 2020/08/20 22:34, Christian Brauner wrote:
>>> On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
If you can handle vfork by other means then I am all for it. There we
On Thu 20-08-20 16:00:54, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
> > On 2020/08/20 22:34, Christian Brauner wrote:
> > > On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
> > >> If you can handle vfork by other means then I am all for it
On Thu 20-08-20 08:41:18, Eric W. Biederman wrote:
[...]
> I expect something like this completley untested patch will work.
Neat. I think you will need to duplicate oom_score_adj_min as well.
I am not familiar with vfork specifics to review this in depth but if
this is correct then it is much mor
On 08/20, Eric W. Biederman wrote:
>
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1139,6 +1139,10 @@ static int exec_mmap(struct mm_struct *mm)
> vmacache_flush(tsk);
> task_unlock(tsk);
> if (old_mm) {
> + mm->oom_score_adj = old_mm->oom_score_adj;
> + mm->oo
On Thu, Aug 20, 2020 at 10:48:43PM +0900, Tetsuo Handa wrote:
> On 2020/08/20 22:34, Christian Brauner wrote:
> > On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
> >> If you can handle vfork by other means then I am all for it. There were
> >> no patches in that regard proposed yet. M
On 2020/08/20 22:34, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
>> If you can handle vfork by other means then I am all for it. There were
>> no patches in that regard proposed yet. Maybe it will turn out simpler
>> then the heavy lifting we have to do
On Thu, Aug 20, 2020 at 02:41:09PM +0200, Michal Hocko wrote:
> On Thu 20-08-20 13:42:56, Michal Hocko wrote:
> > On Thu 20-08-20 13:30:23, Christian Brauner wrote:
> [...]
> > > trying to rely on set_bit() and test_bit() in copy_mm() being atomic and
> > > then calling it where Oleg said after the
Michal Hocko writes:
> On Thu 20-08-20 07:54:44, Eric W. Biederman wrote:
>> ebied...@xmission.com (Eric W. Biederman) writes:
>>
>> 2> Michal Hocko writes:
>> >
>> >> On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
>> >>> Suren Baghdasaryan writes:
>> >>>
>> >>> > Currently __set_oom_adj
On Thu, Aug 20, 2020 at 03:26:31PM +0200, Michal Hocko wrote:
> On Thu 20-08-20 07:54:44, Eric W. Biederman wrote:
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> > 2> Michal Hocko writes:
> > >
> > >> On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
> > >>> Suren Baghdasaryan writ
On Thu 20-08-20 07:54:44, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> 2> Michal Hocko writes:
> >
> >> On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
> >>> Suren Baghdasaryan writes:
> >>>
> >>> > Currently __set_oom_adj loops through all processes in th
ebied...@xmission.com (Eric W. Biederman) writes:
2> Michal Hocko writes:
>
>> On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
>>> Suren Baghdasaryan writes:
>>>
>>> > Currently __set_oom_adj loops through all processes in the system to
>>> > keep oom_score_adj and oom_score_adj_min in sync
Michal Hocko writes:
> On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
>> Suren Baghdasaryan writes:
>>
>> > Currently __set_oom_adj loops through all processes in the system to
>> > keep oom_score_adj and oom_score_adj_min in sync between processes
>> > sharing their mm. This is done for an
On Thu 20-08-20 07:34:41, Eric W. Biederman wrote:
> Suren Baghdasaryan writes:
>
> > Currently __set_oom_adj loops through all processes in the system to
> > keep oom_score_adj and oom_score_adj_min in sync between processes
> > sharing their mm. This is done for any task with more that one mm_u
On Thu 20-08-20 13:42:56, Michal Hocko wrote:
> On Thu 20-08-20 13:30:23, Christian Brauner wrote:
[...]
> > trying to rely on set_bit() and test_bit() in copy_mm() being atomic and
> > then calling it where Oleg said after the point of no return.
>
> No objections.
Would something like the follo
Suren Baghdasaryan writes:
> Currently __set_oom_adj loops through all processes in the system to
> keep oom_score_adj and oom_score_adj_min in sync between processes
> sharing their mm. This is done for any task with more that one mm_users,
> which includes processes with multiple threads (shari
On Thu, Aug 20, 2020 at 01:29:32PM +0200, Michal Hocko wrote:
> On Thu 20-08-20 13:13:55, Michal Hocko wrote:
> > On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> > > On 08/19, Suren Baghdasaryan wrote:
> > > >
> > > > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > > > used the
On Thu 20-08-20 13:30:23, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 01:13:49PM +0200, Michal Hocko wrote:
> > On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> > > On 08/19, Suren Baghdasaryan wrote:
> > > >
> > > > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > > > used
On 08/20, Michal Hocko wrote:
>
> On Thu 20-08-20 13:13:55, Michal Hocko wrote:
> > On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> > > On 08/19, Suren Baghdasaryan wrote:
> > > >
> > > > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > > > used the additional mutex lock in that
On Thu, Aug 20, 2020 at 01:13:49PM +0200, Michal Hocko wrote:
> On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> > On 08/19, Suren Baghdasaryan wrote:
> > >
> > > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > > used the additional mutex lock in that path of the clone() syscall
On Thu 20-08-20 13:13:55, Michal Hocko wrote:
> On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> > On 08/19, Suren Baghdasaryan wrote:
> > >
> > > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > > used the additional mutex lock in that path of the clone() syscall should
> > > not
On Thu 20-08-20 12:55:56, Oleg Nesterov wrote:
> On 08/19, Suren Baghdasaryan wrote:
> >
> > Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> > used the additional mutex lock in that path of the clone() syscall should
> > not affect its overall performance. Clearing the MMF_PROC_SHA
On Thu 20-08-20 12:32:48, Christian Brauner wrote:
> On Thu, Aug 20, 2020 at 11:09:01AM +0200, Michal Hocko wrote:
> > On Thu 20-08-20 10:46:54, Christian Brauner wrote:
[...]
> > > > which includes processes with multiple threads (sharing mm and signals).
> > > > However for such processes the loo
On 08/19, Suren Baghdasaryan wrote:
>
> Since the combination of CLONE_VM and !CLONE_SIGHAND is rarely
> used the additional mutex lock in that path of the clone() syscall should
> not affect its overall performance. Clearing the MMF_PROC_SHARED flag
> (when the last process sharing the mm exits) i
On Thu, Aug 20, 2020 at 11:09:01AM +0200, Michal Hocko wrote:
> On Thu 20-08-20 10:46:54, Christian Brauner wrote:
> > On Wed, Aug 19, 2020 at 05:20:53PM -0700, Suren Baghdasaryan wrote:
> > > Currently __set_oom_adj loops through all processes in the system to
> > > keep oom_score_adj and oom_scor
On Thu 20-08-20 10:46:54, Christian Brauner wrote:
> On Wed, Aug 19, 2020 at 05:20:53PM -0700, Suren Baghdasaryan wrote:
> > Currently __set_oom_adj loops through all processes in the system to
> > keep oom_score_adj and oom_score_adj_min in sync between processes
> > sharing their mm. This is done
On Wed, Aug 19, 2020 at 05:20:53PM -0700, Suren Baghdasaryan wrote:
> Currently __set_oom_adj loops through all processes in the system to
> keep oom_score_adj and oom_score_adj_min in sync between processes
> sharing their mm. This is done for any task with more that one mm_users,
> which includes
On Wed 19-08-20 17:20:53, Suren Baghdasaryan wrote:
> Currently __set_oom_adj loops through all processes in the system to
> keep oom_score_adj and oom_score_adj_min in sync between processes
> sharing their mm. This is done for any task with more that one mm_users,
> which includes processes with
Currently __set_oom_adj loops through all processes in the system to
keep oom_score_adj and oom_score_adj_min in sync between processes
sharing their mm. This is done for any task with more that one mm_users,
which includes processes with multiple threads (sharing mm and signals).
However for such
50 matches
Mail list logo
