On Mon, May 02, 2022 at 11:33:18AM +0800, lipeifeng@xxxxxxxx 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@xxxxxxxxxxxxxx/ 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@xxxxxxxx/ , 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@xxxxxxxx > > From: Andrew Morton > Date: 2022-05-02 09:10 > To: lipeifeng@xxxxxxxx > 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@xxxxxxxx" <lipeifeng@xxxxxxxx> 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. > >
