From: lipeifeng <[email protected]>
The old method will firstly find the space in len(info->length
+ info->align_mask), and get address at the desired alignment.
Sometime, addr would be failed if there are enough
addr space in kernel by above method, e.g., you can't get a
addr sized in 1Mbytes, align_mask 1Mbytes successfully although
there are still (2M-1)bytes space in kernel.
This patch would fix thr problem above by the new method: find the
space in info->length and judge if at the desired info->align_mask
at the same time.
Do a simple test in TIF_32BIT with unmapped_area:
- Try to take addr (size:1M align:2M) until allocation fails;
- Try to take addr (size:1M align:1M) and account how to space can
be alloced successfully.
Before optimization: alloced 0 bytes.
After optimization: alloced 1.9+G bytes.
Signed-off-by: lipeifeng <[email protected]>
---
mm/mmap.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index a28ea5c..cb002f2 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1923,6 +1923,7 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
return -ENOMEM;
low_limit = info->low_limit + length;
+ length = info->length;
/* Check if rbtree root looks promising */
if (RB_EMPTY_ROOT(&mm->mm_rb))
goto check_highest;
@@ -1944,6 +1945,8 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
}
gap_start = vma->vm_prev ? vm_end_gap(vma->vm_prev) : 0;
+ /* Adjust gap address to the desired alignment */
+ gap_start += (info->align_offset - gap_start) & info->align_mask;
check_current:
/* Check if current node has a suitable gap */
if (gap_start > high_limit)
@@ -1984,15 +1987,19 @@ static unsigned long unmapped_area(struct vm_unmapped_area_info *info)
gap_end = ULONG_MAX; /* Only for VM_BUG_ON below */
if (gap_start > high_limit)
return -ENOMEM;
-
+ if (gap_start >= info->low_limit) {
+ gap_start += (info->align_offset - gap_start) & info->align_mask;
+ goto return_gap_start;
+ }
found:
/* We found a suitable gap. Clip it with the original low_limit. */
- if (gap_start < info->low_limit)
+ if (gap_start < info->low_limit) {
gap_start = info->low_limit;
+ /* Adjust gap address to the desired alignment */
+ gap_start += (info->align_offset - gap_start) & info->align_mask;
+ }
- /* Adjust gap address to the desired alignment */
- gap_start += (info->align_offset - gap_start) & info->align_mask;
-
+return_gap_start:
VM_BUG_ON(gap_start + info->length > info->high_limit);
VM_BUG_ON(gap_start + info->length > gap_end);
return gap_start;
--
2.7.4
On Wed, 20 Apr 2022 16:40:39 +0800 [email protected] wrote:
> The old method will firstly find the space in len(info->length
> + info->align_mask), and get address at the desired alignment.
>
> Sometime, addr would be failed if there are enough
> addr space in kernel by above method, e.g., you can't get a
> addr sized in 1Mbytes, align_mask 1Mbytes successfully although
> there are still (2M-1)bytes space in kernel.
>
> This patch would fix thr problem above by the new method: find the
> space in info->length and judge if at the desired info->align_mask
> at the same time.
>
> Do a simple test in TIF_32BIT with unmapped_area:
> - Try to take addr (size:1M align:2M) until allocation fails;
> - Try to take addr (size:1M align:1M) and account how to space can
> be alloced successfully.
>
> Before optimization: alloced 0 bytes.
> After optimization: alloced 1.9+G bytes.
Thanks.
Unfortunately this part of the code is undergoing a lot of change
lately. How serious is this problem? Please tell us how often the
problem is being observed, under what circumstances, etc.
>> Unfortunately this part of the code is undergoing a lot of change
>> lately. How serious is this problem? Please tell us how often the
>> problem is being observed, under what circumstances, etc.
> I have observed some problems in process-TIF_32BIT, such as Wechat
> and others Android APP.
> In the above processes which the single largest remaining free-addr-space
> is 12Mbytes in some case, we found that the processes wound fail to alloc
> a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.
> The idea of this patch is the same as the following patch which is used for
> unmapped_area_topdown, as follows:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3
> Thank you very much indeed to ask such nice question and I wish I have given
> a clear reply. Pls let me know If there are any problems you found.
Hi Andrew Morton：
Pls help to review the patch and can it be merged into next-line?
Thanks very much.
[email protected]
From: [email protected]
Date: 2022-04-21 10:20
To: akpm
CC: peifeng55; linux-mm; linux-kernel; Barry Song; zhangshiming
Subject: Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area
Hi Andrew Morton：
> Unfortunately this part of the code is undergoing a lot of change
> lately. How serious is this problem? Please tell us how often the
> problem is being observed, under what circumstances, etc.
I have observed some problems in process-TIF_32BIT, such as Wechat
and others Android APP.
In the above processes which the single largest remaining free-addr-space
is 12Mbytes in some case, we found that the processes wound fail to alloc
a 12Mbytes(align 1M) in the old methods so that Out-of-Memory.
The idea of this patch is the same as the following patch which is used for
unmapped_area_topdown, as follows:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/mm/mmap.c?id=5c6c46912cc0182fadd4b5f0eab029ccbbcc1ba3
Thank you very much indeed to ask such nice question and I wish I have given
a clear reply. Pls let me know If there are any problems you found.
[email protected]
From: Andrew Morton
Date: 2022-04-21 05:57
To: lipeifeng
CC: peifeng55; linux-mm; linux-kernel; 21cnbao; zhangshiming
Subject: Re: [PATCH] mm: modify the method to search addr in unmapped_area
On Wed, 20 Apr 2022 16:40:39 +0800 [email protected] wrote:
> The old method will firstly find the space in len(info->length
> + info->align_mask), and get address at the desired alignment.
>
> Sometime, addr would be failed if there are enough
> addr space in kernel by above method, e.g., you can't get a
> addr sized in 1Mbytes, align_mask 1Mbytes successfully although
> there are still (2M-1)bytes space in kernel.
>
> This patch would fix thr problem above by the new method: find the
> space in info->length and judge if at the desired info->align_mask
> at the same time.
>
> Do a simple test in TIF_32BIT with unmapped_area:
> - Try to take addr (size:1M align:2M) until allocation fails;
> - Try to take addr (size:1M align:1M) and account how to space can
> be alloced successfully.
>
> Before optimization: alloced 0 bytes.
> After optimization: alloced 1.9+G bytes.
Thanks.
Unfortunately this part of the code is undergoing a lot of change
lately. How serious is this problem? Please tell us how often the
problem is being observed, under what circumstances, etc.