* Liam R. Howlett Liam.Howlett@Oracle.com [230927 13:26]:
- 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=ejti...
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.