> 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:

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.

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.