Re: Re: [PATCH] mm: modify the method to search addr in unmapped_area

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
 
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@xxxxxxxx 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.
 

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux