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 6420BEB64DA for ; Sat, 8 Jul 2023 05:12:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E6F266B0071; Sat, 8 Jul 2023 01:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1F316B0072; Sat, 8 Jul 2023 01:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE74C8D0001; Sat, 8 Jul 2023 01:12:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BB2AE6B0071 for ; Sat, 8 Jul 2023 01:12:34 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 842ACA00E6 for ; Sat, 8 Jul 2023 05:12:34 +0000 (UTC) X-FDA: 80987274228.23.8F626A3 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf04.hostedemail.com (Postfix) with ESMTP id B23A040008 for ; Sat, 8 Jul 2023 05:12:32 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="W/BORHze"; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688793152; 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=rXUkY077M68MN6utXvlpO6chGtWE53cWZb+Nx2rn9lY=; b=14aVmkr8hD3SRUe/5Os78Z8hp2OqJVvFAUZb/RVhT1MSXQftFOr08D1gI0IZoeEOKMvwVn wmSYaadM/lcLn+Ety9/n/uXgnSqbkQNto+SeWTQBsN0A3Lc6k5JjpMAQGA9StNdYbORXss zAcHazkGZYzqAHeEvvEg3P5jzTVMbCs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688793152; a=rsa-sha256; cv=none; b=H31MTAKXIzV8XknHx9yGiAf5GSEK9V4jBpipGeDFLsVBtu/TxUIFuvcYt8EZO7kbLtPO9R l3ko8rjI5ynMOXuOOUObbtV/uimhJKxrCFfpOLxr//ytMqAvAf3aNUUcjNiGul4PB8BcFn A/V1lAiltp3e6HOOmGfmQbJAJqW3//g= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b="W/BORHze"; spf=pass (imf04.hostedemail.com: domain of yuzhao@google.com designates 209.85.160.182 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4036bd4fff1so71831cf.0 for ; Fri, 07 Jul 2023 22:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688793152; x=1691385152; 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=rXUkY077M68MN6utXvlpO6chGtWE53cWZb+Nx2rn9lY=; b=W/BORHzeOA6Eaw0EPkEjw+VQZX9O6vOyeYyaLRz7I2NsrvbLY8cXSi1HNlDg2GWQTP oQ6Gt8yW7EpBVV78uA0XeD1G3cahWrJ4/pJezavlfC6uyNUqJhvk5pBMYMamsvu0tfRn 1GtPrQEKEOW7KhDuHEqf0Ax30T6mxctoa4TsyoM5ZHbkDOpO2e9ERhskEajsDDcHPC0D 2fgF8u9n+1TfOSduMeZ9/hJzX4TRgVLKm3w58bQUh4EBEe1//f3psq7cAQK9Cvv5h4DY Lxsci0uIvAP0yoIbbLyArLYWCS6trNPQvhYizVznTJFwnC6O+at4QUHefAcXytHozS+7 G7sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688793152; x=1691385152; 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=rXUkY077M68MN6utXvlpO6chGtWE53cWZb+Nx2rn9lY=; b=lFsK1+Gvpnzzt/ckQD0tXQXmWljDKhVFtnRl7C1Sf+vJXEM9bYElnWq7WMoDWIOxy2 TEVzzgJTfx8ykrLrA/BUkjwyLyWjtfuFu0NPj4whsEDx+rjblsnlRbSQVjLGLGqzlHmT zn09MEKy3kI02BkveWNjo57kpmozql+f055YVRNKs57PClIJIS5kyi1F8U3fjN+Vdsq5 bH91AJ53xPxb8OQ38tWcH/j9M38g/WoNd8A1q0LJo2oAGiGYc+9+d/YbhsKZC0mDaA9e SATUd+BmRA2g897Yj6jI5az9F6Y1UG8uq7X1XoMqoz6gQeKpbcqqwIHE0LLuOYpaliRE G21A== X-Gm-Message-State: ABy/qLbIZ41cqsnocDX2cTng/YKPlbhu2BjNDei8XLcmq2Yq9U2b1vRF WoeZ/JhZ/3lYr8XKNB3UaoaBpbcVlmh5jEv4Db4QsA== X-Google-Smtp-Source: APBJJlHuQTOPWRtl7jg/V4OnXW/ZTFrOSW3+quFXTBdITUsD5EFZO5SZW/dIe0qnjbxQ48tUMYpxEwDUPuFScMqjhYU= X-Received: by 2002:ac8:4e8e:0:b0:3f9:a770:7279 with SMTP id 14-20020ac84e8e000000b003f9a7707279mr62041qtp.9.1688793151715; Fri, 07 Jul 2023 22:12:31 -0700 (PDT) MIME-Version: 1.0 References: <20230707165221.4076590-1-fengwei.yin@intel.com> <20230707165221.4076590-3-fengwei.yin@intel.com> In-Reply-To: <20230707165221.4076590-3-fengwei.yin@intel.com> From: Yu Zhao Date: Fri, 7 Jul 2023 23:11:55 -0600 Message-ID: Subject: Re: [RFC PATCH 2/3] mm: handle large folio when large folio in VM_LOCKED VMA range To: Yin Fengwei Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, shy828301@gmail.com, akpm@linux-foundation.org, willy@infradead.org, david@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B23A040008 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: w3943mjo46cpd8jbqy17c7dah8qojt3e X-HE-Tag: 1688793152-459560 X-HE-Meta: U2FsdGVkX19mDIOjqZLx/uNAXToIWUEM3+Pc6ehPVeW/FZOlxIXeTQT5Hb6SRYQKjSBJ9YiBproL1kO9n41RUZg99m2o8CRHMJzQwCaWprvYBYhDEhOgfEYSetZQNWqQJNf+dUgesr5srM8H7LVOlBzIqvsD5+Oa1vnJYHG9pj5+VGUE/7APWut5PrTxEnuGywW8vg9M1zEyqqF7U4NwdPoGh0fUm2s3gSD/07y0yebD418IKjrtoHi3WZVyxKxvwRKNAeKgUbSSsFL1FLsDebH3/O/A8l1q+/oQarpg9rbh/bebnVqfbFIALMCYp6Bs+woxqwkAynWsEqCT4Yo7a+2ke/72xidWCGY8uuG9/DIPyX+7MwcM/ULYwlXt4jCyBHGii9ThojhZmD3vKupvh99G/MmO+QIRAu8QoNe/fw0jfJz72bt8YdtAANMCsrqSomB4slmVbFsl7fMJqxbRln+K4eqciAQAJB04I3Ie35uSEhQmttT4vmAADQmKkcUr6lHWxedQhunpvIAVxxjqJdXgvW+ZlXueGwOSlVnEKWhaRTLcLkaElwCGudetxQ2lDoyqDqrDrJ1j0qnRemsBQ3HOoV33bOHL6mhLhAPxKQ5CK7FcFnrU1a9tNm22RX4WpoIBhqAVUMgC8m26UaadUdpUbvO42Y9YVJ2FTu1PoXUe8JvfXYxrLtoFOdCE9ZCA/lYLfpgKumqkoDEpWySuR5hz7qSoUTbOb3c1zr6NchUpG2fFNnuOIgchiMWUHX7rxUmJctP2G284iV0reFeWOYaxFoep3OPNR2KzilJefe1EFCpSzdbxlVhoZ8YehmHBgDqWSwz3dkdkB5TnSHw56omuHfqM2JXcfFkgwnRwyApL0McQk1FYqm9NJoIb+nAZwc053hNrtxuo2kyI9zlDg7pBnM7CPKUohP8SKNWtEH0NPNGK6c2jVKrOQPLhhXZwaqOM0wa230mWYfVb324 hF6uOslX 7twSme3t8oY6NFRuUjoBIwjuxImP0fbQUSZUpgPxwcBLh/twxkvNYYmzLn0eTvDNuQK6M/xyeAPnWuiFtm0w6Ad9TvGOrQJiqPfIbudPkDHyalqnatr1h34JhsiRdWUaIey90J03sLUVuSoP74Ysne5WXanlzgaIzLOaYal6pg9TbAUoSEnAGBpHvZr69vW5Vp57vuNAHgHm7C6omSRplo6NaQjjiwCbZkvyJwDBa+vqqNoZfuJV70oUpYBxbiSBHINX9f2AguPEEDOr4qwfgxFMhdFH3iNGsrnGLi+TjYyOTt3E= 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: On Fri, Jul 7, 2023 at 10:52=E2=80=AFAM Yin Fengwei = wrote: > > If large folio is in the range of VM_LOCKED VMA, it should be > mlocked to avoid being picked by page reclaim. Which may split > the large folio and then mlock each pages again. > > Mlock this kind of large folio to prevent them being picked by > page reclaim. > > For the large folio which cross the boundary of VM_LOCKED VMA, > we'd better not to mlock it. So if the system is under memory > pressure, this kind of large folio will be split and the pages > ouf of VM_LOCKED VMA can be reclaimed. > > Signed-off-by: Yin Fengwei > --- > mm/internal.h | 11 ++++++++--- > mm/rmap.c | 3 ++- > 2 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/mm/internal.h b/mm/internal.h > index 66117523d7d71..c7b8f0b008d81 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -637,7 +637,8 @@ static inline void mlock_vma_folio(struct folio *foli= o, > * still be set while VM_SPECIAL bits are added: so ignore it = then. > */ > if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) =3D=3D VM_L= OCKED) && > - (compound || !folio_test_large(folio))) > + (compound || !folio_test_large(folio) || > + folio_in_range(folio, vma, vma->vm_start, vma->vm_end))) > mlock_folio(folio); > } > > @@ -645,8 +646,12 @@ void munlock_folio(struct folio *folio); > static inline void munlock_vma_folio(struct folio *folio, > struct vm_area_struct *vma, bool compound) > { > - if (unlikely(vma->vm_flags & VM_LOCKED) && > - (compound || !folio_test_large(folio))) > + /* > + * To handle the case that a mlocked large folio is unmapped from= VMA > + * piece by piece, allow munlock the large folio which is partial= ly > + * mapped to VMA. > + */ > + if (unlikely(vma->vm_flags & VM_LOCKED)) > munlock_folio(folio); > } > > diff --git a/mm/rmap.c b/mm/rmap.c > index 2668f5ea35342..7d6547d1bd096 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -817,7 +817,8 @@ static bool folio_referenced_one(struct folio *folio, > address =3D pvmw.address; > > if ((vma->vm_flags & VM_LOCKED) && > - (!folio_test_large(folio) || !pvmw.pte)) { > + (!folio_test_large(folio) || !pvmw.pte || > + folio_in_range(folio, vma, vma->vm_start, vma->vm_end= ))) { > /* Restore the mlock which got missed */ > mlock_vma_folio(folio, vma, !pvmw.pte); > page_vma_mapped_walk_done(&pvmw); It needs to bail out if large but not within range so that the references within the locked VMA can be ignored. Otherwise, a hot locked portion can prevent a cold unlocked portion from getting reclaimed.