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 0086BC7EE29 for ; Thu, 25 May 2023 19:51:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40B05900003; Thu, 25 May 2023 15:51:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3929D900002; Thu, 25 May 2023 15:51:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 233A1900003; Thu, 25 May 2023 15:51:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 0FEDA900002 for ; Thu, 25 May 2023 15:51:38 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CF3BE80C9E for ; Thu, 25 May 2023 19:51:37 +0000 (UTC) X-FDA: 80829822234.26.1F76EC0 Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by imf17.hostedemail.com (Postfix) with ESMTP id 5173D4001B for ; Thu, 25 May 2023 19:51:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=Swg9j2dX; dmarc=none; spf=pass (imf17.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.169 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685044295; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dQtVi/2EvKDxLlI3bV7/HKRrNErdeyi9JL2Y1lgW7U0=; b=q3/M7pzKgyNGyi4BOJwfku5UI3fwdoq2jQITy/zgGn3omcqAhGFZIMa6VNgY1JYH1dDLDp kr8VbXnFi8IC5bwC4EWJj4VDd49fiArj22yYh9/iP5UQ/VnFN896o5kLAFp9HBqm2AJcDG 5Wc9f3nlMcr4dxqXrXY/pUAoMet2BRY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=joelfernandes.org header.s=google header.b=Swg9j2dX; dmarc=none; spf=pass (imf17.hostedemail.com: domain of joel@joelfernandes.org designates 209.85.128.169 as permitted sender) smtp.mailfrom=joel@joelfernandes.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685044295; a=rsa-sha256; cv=none; b=KziJwCIMVB43UkDU7FqDi2fpMXwdFJEF7FlWF/pZZodZNInpjUAzprMJcuHy9eJwWjaj5x 9WhXygbhTKP5dtGj1zN94bv1356fmFA0ILrPG5Nn0jxk87U8ixBtDegUY5QUc7s02OLf8o pVLaGCAYBb3mFp7u+wNpWHpkd0LQLDU= Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-565a022ef06so1722717b3.3 for ; Thu, 25 May 2023 12:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1685044295; x=1687636295; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=dQtVi/2EvKDxLlI3bV7/HKRrNErdeyi9JL2Y1lgW7U0=; b=Swg9j2dX6OFqvp/TbbvMAvLSnvq4lrSFepdc7WisPr485X0zxndyAOTcnYAWuQlJnD PWBVlHe9ycm6hZ1quoMvEnRLVj6JFbsPmhJaylAoUIIUCaxFkkFWYjRngOn75C4lG5dq 0rT6q9ds9flykVL2GXwJMgoWlC05gr+EpUapg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685044295; x=1687636295; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dQtVi/2EvKDxLlI3bV7/HKRrNErdeyi9JL2Y1lgW7U0=; b=V5NpZkGDR0RYqCdwT6oZZcsdzbCKrO3PTj5a0+oxp8Wrkt0d5tEcDxyXJxTM/3a5HJ +1YG72awf3vvozytcvinZADoyKHcBcEaTm+oNQy+dAmGgZs1dScavic01iGjl1nhczWq mWCmLW9TH20JtLLhMehBy0irtuPhya+4I2SYwl2gIPoPlZIQu8rMEO5MiPGyG5QETC7z UUPfVYC4CPTkYeddY8jKD3eZnNBxQF8L9qANpYVByJAsWsQI+u0bwZpYuajnEFFMTgaf nTrOGESDmy3qrBdsGCm0Ku0EJKmCJanLv5FXnb81GVDrQY5rX4QS847keAy93HofHT8J s38g== X-Gm-Message-State: AC+VfDwOg6EkYhUYSl+j+iyElZhfB+EmY9j2j65UizGlR8uiUhqMyPI6 /Do7i++fIdSSupGMzK4pzi4V6eayz7sxwBmXfkCnKg== X-Google-Smtp-Source: ACHHUZ48YLnlxKAvKA5r3j7SV3FxQvvF2F8Z3cb2tPTI6RLteNgzhMgofaL8DiLyWzreAJOpz+qbXIlc7eGttaRZhwI= X-Received: by 2002:a81:6bd6:0:b0:564:dd8d:b0d0 with SMTP id g205-20020a816bd6000000b00564dd8db0d0mr774098ywc.22.1685044294749; Thu, 25 May 2023 12:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20230524153239.3036507-1-joel@joelfernandes.org> <20230524153239.3036507-2-joel@joelfernandes.org> In-Reply-To: From: Joel Fernandes Date: Thu, 25 May 2023 15:51:23 -0400 Message-ID: Subject: Re: [PATCH v3 1/6] mm/mremap: Optimize the start addresses in move_page_tables() To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, Shuah Khan , Vlastimil Babka , Michal Hocko , Lorenzo Stoakes , Kirill A Shutemov , "Liam R. Howlett" , "Paul E. McKenney" , Suren Baghdasaryan , Kalesh Singh , Lokesh Gidra Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 5173D4001B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: sxtwy4g5en7eebhbxonngoc13suhdu94 X-HE-Tag: 1685044295-523479 X-HE-Meta: U2FsdGVkX19GgG2Xb7TvQzpC2V+h2jEVqagubrwftMEREQgdxKgxpUdA7ZZoLCNazW5S1SQs+GO4udqZ1by0sFuOvlgO/rTYrM9KKEUNl+Vp3TfWe3P5HGtRWfCozm6dy7ukrMmp9kFvzrPg82zGTb5gSClhtitHDJz2+58p1foLK+62F0HZ1boIdUVKY39ZlhU+v5nk7kVphd6CnVT+SgxAu8EGJI7tkWOoFb2XMfAEzmARzNp1VgH1OGBzp8Xt0cJbnRTCXpOngCD68Ii98DOfdB73GsJl9gR+NWV6Ha7j19KN11l/IckF+QFaC1VcFmCgAst234AkK9iAekB0B6d6wmwz2Ihb+1FrQxtYfe2NwmSKBZG7PyENDiDu3WxAFpRV+G79PrLlveDUK0Q4nX8llshALbnofDh0LSKwOySNl7r+z0AY9gCXe9LJau8n8AwSyXUfGdwUu6CD7h+ydufaXELQoWHmQmO/m7D09aY2IJzfUZmmxDqx3oFSxMe2XHiP9kzA97PUl/2LqlFiJ+Rbed443tp5/RIMtzxr5GnuN+CjiVIVwKIMMjXlcdwotLXcHMDeBL9m33X8QQtdtmArq6vH3fEreJ0uHqQ4q2/0Eh6s+XGIB+bXxwTyBBw0ZuAydjhyDVsEQeVvvH22/UDB2bKlYU7JASS38Lc6kE8xSotVNtaNH8hCuXAyEFtSNzTUea6mpJgvP9kMghh+Gx1jCWECQlkyy8r8ciOqv67JG3WyqzqSSmNfWTppR/zP2tKU1qg+iQntMM3M9wBfAV9y4Y+xy3kiXjY5jL1G/6absGJQLYjAyITn4ciAJ7Hb3+y7zMi9IutyQiLJvy6G1DuHyqpuFbvAN1dyeHTwufPLr/1Yc4CIRfMOZ150s6LY+zPlx+js7c97Wvh2rGhrnSEtkzY7yTnkvE97w0kka1vsF2GKyjeI7v9OrP971xMUYCD2aMiEUXHDGZf49Ic OamKbrIL +j63m87JIcbEOeCInWMB1nUf92b696VTpC9V1P1Sdy9lbZgGG8CyTGbCb71+8nS/5buytsXMq1L421QnNa66M5+YyzWcwnnNj9d1FOfpkP5Wyl504M+1mHLOuEONvmg/ldc7KuV8Caa7yTjZgf3jaRofadnYcrD8baxIjDwJrR1MSrtf+3wwRW/YXWXTPYQgbR/pef5aj70Wx6VE+H3DKP5GTBSvUW0AIcuXK3BeGGb42SGM+ADzYplkn1HULzOPaiYZFTsWbM2amSUO1+oPrHIr4OaNytGBusn89XJowikONIn1eDDs9S8TEX9ooLOGPcTUJiRwebtsEeGJVPh1f0yUykbBxCF4fczf2Pif0eKVPu3JhG926fA8CZe7kr0/TcGC5uyJh2YvLHV0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Linus, On Wed, May 24, 2023 at 7:23=E2=80=AFPM Linus Torvalds wrote: > > Hmm. I'm still quite unhappy about your can_align_down(). > > On Wed, May 24, 2023 at 8:32=E2=80=AFAM Joel Fernandes (Google) > wrote: > > > > + /* If the masked address is within vma, we cannot align the add= ress down. */ > > + if (vma->vm_start <=3D addr_masked) > > + return false; > > I don't think this test is right. > > The test should not be "is the mapping still there at the point we > aligned down to". > > No, the test should be whether there is any part of the mapping below > the point we're starting with: > > if (vma->vm_start < addr_to_align) > return false; > > because we can do the "expand the move down" *only* if it's the > beginning of the vma (because otherwise we'd be moving part of the vma > that precedes the address!) You are right, I missed that. Funny I did think about this case you mentioned. I will fix it in the next revision, thanks. > (Alternatively, just make that "<" be "!=3D" - we're basically saying > that we can expand moving ptes to a pmd boundary *only* if this vma > starts at that point. No?). Yes, I prefer the "!=3D" check. I will use that. > > > + cur =3D find_vma_prev(vma->vm_mm, vma->vm_start, &prev); > > + if (!cur || cur !=3D vma || !prev) > > + return false; > > I've mentioned this test before, and I still find it actively misleading. > > First off, the "!cur || cur !=3D vma" test is clearly redundant. We know > 'vma' isn't NULL (we just dereferenced it!). So "cur !=3D vma" already > includes the "!cur" test. > > So that "!cur" part of the test simply *cannot* be sensible. Ok, I agree with you now. > And the "!prev" test still makes no sense to me. You tried to explain > it to me earlier, and I clearly didn't get it. It seems actively > wrong. I still think "!prev" should return true. Yes, ok. Sounds good. > You seemed to think that "!prev" couldn';t actually happen and would > be a sign of some VM problem, but that doesn't make any sense to me. > Of course !prev can happen - if "vma" is the first vma in the VM and > there is no previous. > > It may be *rare*, but I still don't understand why you'd make that > "there is no vma below us" mean "we cannot expand the move below us > because there's something there". > > So I continue to think that this test should just be > > if (WARN_ON_ONCE(cur !=3D vma)) > return false; I agree with this now. > > because if it ever returns something that *isn't* the same as vma, > then we do indeed have serious problems. But that WARN_ON_ONCE() shows > that that's a "cannot happen" thing, not some kind of "if this happens > than don't do it" test. > > and then the *real* test for "can we align down" should just be > > return !prev || prev->vm_end <=3D addr_masked; Agreed, that's cleaner. > Because while I think your code _works_, it really doesn't seem to > make much sense as it stands in your patch. The tests are actively > misleading. No? True, your approach makes me want to improve on writing cleaner code than being excessively paranoid. So thank you for that. These patches have been tricky to get right so thank you for your continued input and quick feedback. I will add a test for the case you mentioned above where the address to realign wasn't in the VMA's beginning. thanks, - Joel