| Message ID | 20220420084039.1431-1-lipeifeng@oppo.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: modify the method to search addr in unmapped_area | expand |
On Wed, 20 Apr 2022 16:40:39 +0800 lipeifeng@oppo.com 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.
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. lipeifeng@oppo.com 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 lipeifeng@oppo.com 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. lipeifeng@oppo.com From: lipeifeng@oppo.com 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. lipeifeng@oppo.com 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 lipeifeng@oppo.com 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.
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;