From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 53BE2C433F5 for ; Mon, 9 May 2022 11:45:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAE6C6B0071; Mon, 9 May 2022 07:45:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5E4A6B0073; Mon, 9 May 2022 07:45:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C27696B0074; Mon, 9 May 2022 07:45:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B569D6B0071 for ; Mon, 9 May 2022 07:45:24 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 87648120EC7 for ; Mon, 9 May 2022 11:45:24 +0000 (UTC) X-FDA: 79446024168.12.E802BF8 Received: from server.lespinasse.org (server.lespinasse.org [63.205.204.226]) by imf10.hostedemail.com (Postfix) with ESMTP id 272F6C0057 for ; Mon, 9 May 2022 11:45:02 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-67-ed; t=1652096721; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from; bh=A7VZnkOooDmMVt0zmVkAt2c4XohtDtf3/DK9V1jJLOM=; b=6NIYylgjhPZog+yLwPODPJcIfvcr2ocFDpkqISi70tNxjI7/Rel1tXmowCuX+rKmvyQ0t U5XYZcoyTYbdnViCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lespinasse.org; i=@lespinasse.org; q=dns/txt; s=srv-67-rsa; t=1652096721; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to : from; bh=A7VZnkOooDmMVt0zmVkAt2c4XohtDtf3/DK9V1jJLOM=; b=QqIDruEzcYTOkudQdoZ/epVo8dv8ZoFkhL3ztjpET6S2nM91npiPlvF4tBDb2OrJ9Zlqf 4gfNS9L6uVA9/dFOQw2eL/CnoRcplDDly4lIDHp6oGZ7oglzlelpg/9fZaYmFHuKCDuI3rS AN+WY15QcCV1Io2u9sjbqv9xOaSI53TwnmZGB4/RiGqxOHkMLCzUVrfiFknVF0rKZE5ikWx 6Ynasu07e15ty34sCnZI0ejeYOf5XaT/ptwLTnxBZ0oybifX/2JPjA4UDiZ9hE1/zVSOiKj R253BT8DQBBh764iBmuw7+zSmw3GGes4T6fXtv2XPuSVDau7gRDm+7UUGIlw== Received: by server.lespinasse.org (Postfix, from userid 1000) id 5C500160B4E; Mon, 9 May 2022 04:45:21 -0700 (PDT) Date: Mon, 9 May 2022 04:45:21 -0700 From: Michel Lespinasse To: "lipeifeng@oppo.com" Cc: akpm , michel , hughd , linux-mm , linux-kernel , Barry Song <21cnbao@gmail.com>, zhangshiming , peifengl55 Subject: Re: Re: [PATCH] mm: fix align-error when get_addr in unmapped_area_topdown Message-ID: <20220509114521.GA9512@lespinasse.org> References: <20220412081014.399-1-lipeifeng@oppo.com> <20220412142238.93e36cc4095e4e0b362db348@linux-foundation.org> <2022041310411426044561@oppo.com> <2022050110235766139218@oppo.com> <20220501181041.6d53cb9ed54bf697840e36cc@linux-foundation.org> <2022050211305415626916@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2022050211305415626916@oppo.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 272F6C0057 Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=lespinasse.org header.s=srv-67-ed header.b=6NIYylgj; dkim=pass header.d=lespinasse.org header.s=srv-67-rsa header.b=QqIDruEz; spf=pass (imf10.hostedemail.com: domain of michel@lespinasse.org designates 63.205.204.226 as permitted sender) smtp.mailfrom=michel@lespinasse.org; dmarc=pass (policy=none) header.from=lespinasse.org X-Rspam-User: X-Stat-Signature: j8653q5w558wo1twed3m9r13gy7xap4s X-HE-Tag: 1652096702-541433 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000020, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, May 02, 2022 at 11:33:18AM +0800, lipeifeng@oppo.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@oppo.com >   > From: Andrew Morton > Date: 2022-05-02 09:10 > To: lipeifeng@oppo.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@oppo.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. >   >