* Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> [230927 13:26]: > * Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> [230927 13:14]: > > On Wed, 27 Sep 2023 12:07:44 -0400 "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > > > 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. The initial call to vma_merge() is correct, but on the second call vma is the same as prev so it won't attempt to merge prev again. I think it would only cause one extra call to vma_merge(). So I think you are correct, CPU usage will not increase very much. But, there also will not be a bogus OOM. There will just be two calls to vma_merge() for the same VMA when there is an OOM even and we could have merged prev. I doubt the user would notice anything and they have bigger memory issues at that time.
