lkml.org 
[lkml]   [2023]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] mmap: Fix vma_iterator in error path of vma_merge()
* Andrew Morton <akpm@linux-foundation.org> [230927 13:14]:
> On Wed, 27 Sep 2023 12:07:44 -0400 "Liam R. Howlett" <Liam.Howlett@oracle.com> wrote:
>
> > When merging of the previous VMA fails after the vma iterator has been
> > moved to the previous entry, the vma iterator must be advanced to ensure
> > the caller takes the correct action on the next vma iterator event. Fix
> > this by adding a vma_next() call to the error path.
> >
> > Users may experience higher CPU usage, most likely in very low memory
> > situations.
>
> Looking through this thread:
>
> > Closes: https://lore.kernel.org/linux-mm/CAG48ez12VN1JAOtTNMY+Y2YnsU45yL5giS-Qn=ejtiHpgJAbdQ@mail.gmail.com/
>
> I'm seeing no indication that the effect is CPU consumption? Jann is
> excpecting bogus oom-killing?

His testing injected a bogus oom, but since the vma iterator may get
stuck in a "I can merge! oh, I'm out of memory" loop due to the
vma_merge() called with the same VMA in this loop, I would expect it to
be increased CPU usage when almost out of memory until a task is killed.
I don't think he expected a bogus OOM since we are using GFP_KERNEL
during mm/internal.h:vma_iter_prealloc() calls.

\
 
 \ /
  Last update: 2023-09-27 19:27    [W:0.116 / U:1.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site