Message-ID: <2022051610294089439420@oppo.com>
Date:   Mon, 16 May 2022 10:43:39 +0800
From:   "lipeifeng@...o.com" <lipeifeng@...o.com>
To:     michel <michel@...pinasse.org>
Cc:     akpm <akpm@...ux-foundation.org>, michel <michel@...pinasse.org>,
        hughd <hughd@...gle.com>, linux-mm <linux-mm@...ck.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        "Barry Song" <21cnbao@...il.com>,
        zhangshiming <zhangshiming@...o.com>,
        peifengl55 <peifengl55@...il.com>
Subject: Re: Re: [PATCH] mm: fix align-error when get_addr in unmapped_area_topdown

Hi michel:

Thank you for your reply.
I am sorry for my late reply.

> This previous thread is very relevant here:
> https://lore.kernel.org/lkml/CANN689G6mGLSOkyj31ympGgnqxnJosPVc4EakW5gYGtA_45L7g@mail.gmail.com/
 
> I am sorry that I had confused you with the original poster on that
> thread - your proposed changes are very similar. That said, I still
> have the exact same concerns that I had at the time. The current
> search algorithm is guaranteed to find a gap in O(log N) time, if there
> is an available gap of size (requested_size + alignment - page_size).
> The modified search only requires an available gap of the requested
> size and alignment, but it can take O(N) time which might be too slow.
> Maybe we could afford the slow search if it's only used as a fallback
> when the fast search fails, but very few people would ever execute
> that fallback and that makes it hard to test / easy for bugs to hide in.

In my opions, my new methods to search addr take O(log N) time too,
is it right? i will only add more action to judge if the space is available
at the same time.

> If I understand your message at
> https://lore.kernel.org/lkml/202204241833454848958@oppo.com/ ,
> it seems like some andoid apps such as wechat are filling up
> a 32-bit address space such as there is no 13MB gap available anymore
> (as would be required by the current search), but there are still some
> 12MB gaps aligned on a 1MB boundary, which they are then trying to
> allocate from. It seems very odd to me that one would find themselves
> in that situation, could you give us some details as to how that happened ?
> Do you know what the app is trying to do to fill the address space that way ?
> Also, why is this odd behavior considered to be a kernel issue - was the
> app previously running on a (quite old !) kernel that didn't have the fast
> vma gap search, and is now failing when ported to a more recent kernel ?

1. Wechat just one of the case we found to space unsuccessfully by the old way,
others app, like sgame、taobao and so on， which have been found the same
issue(The allocated size is 1M~12M).  Unfortunately, we can not see how the 
above apps operate.

2. the patch will sovle the another problems, it can add more vma-merge in some
case. e.g., some gpu will alloc vma-space  on a 1MB boundary, if there are much
vma-free-space(less than 1M+64kytes) in system, it can not be alloced to 64kbtes
on a 1MB boundary, so that more vma would be need.



lipeifeng@...o.com
 
From: Michel Lespinasse
Date: 2022-05-09 19:45
To: lipeifeng@...o.com
CC: akpm; michel; hughd; linux-mm; linux-kernel; Barry Song; zhangshiming; peifengl55
Subject: Re: Re: [PATCH] mm: fix align-error when get_addr in unmapped_area_topdown
On Mon, May 02, 2022 at 11:33:18AM +0800, lipeifeng@...o.com wrote:
> Hi Andrew：
>
> Thanks for your quick response.
>
> > They caused me some merge issues against mapletree, which I had
> > resolved.  Mapletree is dropped at present so I set these patches aside
> > until the next version of the mapletree patches are available.
>
> Do we have a definite time for the next available version of the mapletree patches?
> Excuse me, is it possible for our patch to be independent of mapletree and brought in separately?
 
I think it's unavoidable that there will be a conflict with maple tree
because they are changing the way we track gaps between vmas.
 
> > I've been holding your patches until Michel Lespinasse has had time to
> > review them (and hopefully explain them to me ;)).  Please review
> > earlier comments which Michel has provided and ensure that those
> > comments have been fully addressed so we can hopefully move forward on
> > this.
>
> We will reply soon if Mr.Lespinasse provideds any advices or question.
> And I haven't received any reply from Mr.Lespinasse yet, pls let me know
> if I missed the reply.
 
This previous thread is very relevant here:
https://lore.kernel.org/lkml/CANN689G6mGLSOkyj31ympGgnqxnJosPVc4EakW5gYGtA_45L7g@mail.gmail.com/
 
I am sorry that I had confused you with the original poster on that
thread - your proposed changes are very similar. That said, I still
have the exact same concerns that I had at the time. The current
search algorithm is guaranteed to find a gap in O(log N) time, if there
is an available gap of size (requested_size + alignment - page_size).
The modified search only requires an available gap of the requested
size and alignment, but it can take O(N) time which might be too slow.
Maybe we could afford the slow search if it's only used as a fallback
when the fast search fails, but very few people would ever execute
that fallback and that makes it hard to test / easy for bugs to hide in.
 
If I understand your message at
https://lore.kernel.org/lkml/202204241833454848958@oppo.com/ ,
it seems like some andoid apps such as wechat are filling up
a 32-bit address space such as there is no 13MB gap available anymore
(as would be required by the current search), but there are still some
12MB gaps aligned on a 1MB boundary, which they are then trying to
allocate from. It seems very odd to me that one would find themselves
in that situation, could you give us some details as to how that happened ?
Do you know what the app is trying to do to fill the address space that way ?
Also, why is this odd behavior considered to be a kernel issue - was the
app previously running on a (quite old !) kernel that didn't have the fast
vma gap search, and is now failing when ported to a more recent kernel ?
 
> Thank you very much indeed.
>
> lipeifeng@...o.com
>  
> From: Andrew Morton
> Date: 2022-05-02 09:10
> To: lipeifeng@...o.com
> CC: michel; hughd; linux-mm; linux-kernel; Barry Song; zhangshiming; peifengl55
> Subject: Re: [PATCH] mm: fix align-error when get_addr in unmapped_area_topdown
> On Sun, 1 May 2022 10:26:35 +0800 "lipeifeng@...o.com" <lipeifeng@...o.com> wrote:
>  
> > Why did the two patches suddenly disappear without any email or notice for us?
> > And they had been merged in linux-next.git on April 5 and 13.
>  
> They caused me some merge issues against mapletree, which I had
> resolved.  Mapletree is dropped at present so I set these patches aside
> until the next version of the mapletree patches are available.
>  
>  
> I've been holding your patches until Michel Lespinasse has had time to
> review them (and hopefully explain them to me ;)).  Please review
> earlier comments which Michel has provided and ensure that those
> comments have been fully addressed so we can hopefully move forward on
> this.
>  
>  

Powered by blists - more mailing lists