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 34CDBEB64DA for ; Sat, 8 Jul 2023 05:56:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B78428D0007; Sat, 8 Jul 2023 01:56:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B017D8D0001; Sat, 8 Jul 2023 01:56:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A3648D0007; Sat, 8 Jul 2023 01:56:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 84C408D0001 for ; Sat, 8 Jul 2023 01:56:53 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4BD5F160114 for ; Sat, 8 Jul 2023 05:56:53 +0000 (UTC) X-FDA: 80987385906.14.37E4C0E Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by imf14.hostedemail.com (Postfix) with ESMTP id 8775E10000B for ; Sat, 8 Jul 2023 05:56:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=NwooO6Ec; spf=pass (imf14.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.171 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=1688795811; 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=ktwdl5TQFeIYyiCaVsJWEC8esxXxEXEFyV/rHghDt34=; b=E0d/jn4paB/MzMo2PFmM29dXBfuDWnUAY/rfVL56olKWa6mXGhJi2xy6+ZkLw3gXDT2q3P h9GEIxtSH6bayPlkzunuOwVuTPx51kApBVkRhJbMj0dBAQ90Var86rHn6i3GbpkuYFruSU 064HODs8uTdq8k9RQqAzgPUO++YmmYM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688795811; a=rsa-sha256; cv=none; b=eQ1Ac46UY8RcXoxm3sdh4Iz1qGr2QRqcCXN9KRaQDzk0ncMH4gzmIUbDlPA38wIVM54SSt RBWfjgGnvAc/4egns87gk3P9bQ7n7DV3+BunVQxe68OpmfqDy7VuBFbUTr+gJr2hXVvGzT Jivdxr0bA5RuHFESxJGgyBElc86fCeQ= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=NwooO6Ec; spf=pass (imf14.hostedemail.com: domain of yuzhao@google.com designates 209.85.166.171 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-il1-f171.google.com with SMTP id e9e14a558f8ab-346099c6f43so43355ab.0 for ; Fri, 07 Jul 2023 22:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688795810; x=1691387810; 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=ktwdl5TQFeIYyiCaVsJWEC8esxXxEXEFyV/rHghDt34=; b=NwooO6EcfzdeygoL3cBGFSyNJIgQ20cApSfodbSdbSVMO2MIpHWrS1S54gfdhEBCsC 21YPDxlG3BuvSUMYXR4Dzh8KjPLk7220fxQtMKplb/2uFa6aygBFBCmbE/uJJWbe3eO8 7AyNg8faOSLWklZIMDME1NOCNF72HqKMHjli4yKtJcIGgP4qf6u1eXpkNSfuVHgLsyhm GepkIJPLMvcIaF4Uy1cCNWvAl/8/U8NB4sAftxhT7W6FMAX6GxZva+tyqxgBF52vAcEb pRAWm839dn9t2Psckm90y4GTQC78RemuHjQejXuSyxJiH/DIsb62UZBTz3tuLjJttrZ9 AdAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688795810; x=1691387810; 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=ktwdl5TQFeIYyiCaVsJWEC8esxXxEXEFyV/rHghDt34=; b=j/NBBhEaawgw1+lGTGcA2rMSq3SOgLTTyHDYnXt6hHShQ0YSNArIPO5ONnDmQV+pHE XdQ59RoVK1i6jKNLBijxH5RvQLC8fLKgBNyWP1BHCtRSABkqhD+shHH1O1fK5Rq3H+W1 qbIBgUfqZTLIsDQMrTbGulg4XOtlzl9382OHrbxLV6+YLgvjXmOPe16H5/S6YgbpCihP xNw64aUzNcpOgVht1pGr0bPkZz9QyWj/LcYDX69Q7z03cAUt7lQ3j8PIKfdnGnl27VMi 1VVD0a+i1S0qUSElQJfiIAr2U9B9hfMKbCrnWfGl9EeYdnYLolp9LdLoWUjinVzU7fkr R6Fw== X-Gm-Message-State: ABy/qLZILSwRr2kLVZuNBM5mKUlW5/Ba9aygfbKXRtjD6mXOb83/xV+o 4pOYnR+E4anGfsi761sojASTiKzYJPabJkCu1G08aw== X-Google-Smtp-Source: APBJJlFDdATi0FYftaqlgzOrtA94z7xNS20rW6NoNjUL5YYazYoP1NC3vVM6DtdDqwT7ltg2ogQlIgYEVynjKq1BYdw= X-Received: by 2002:a92:c56e:0:b0:33d:f067:8fa4 with SMTP id b14-20020a92c56e000000b0033df0678fa4mr120021ilj.16.1688795810519; Fri, 07 Jul 2023 22:56:50 -0700 (PDT) MIME-Version: 1.0 References: <20230707165221.4076590-1-fengwei.yin@intel.com> <20230707165221.4076590-3-fengwei.yin@intel.com> <928bb406-f09b-358e-c3cb-72ddd53a2793@intel.com> In-Reply-To: <928bb406-f09b-358e-c3cb-72ddd53a2793@intel.com> From: Yu Zhao Date: Fri, 7 Jul 2023 23:56:14 -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: 8775E10000B X-Rspam-User: X-Stat-Signature: 488hf7ppe5sm14nhyuruq1dyauta5qed X-Rspamd-Server: rspam03 X-HE-Tag: 1688795811-561364 X-HE-Meta: U2FsdGVkX1/zAdnA4x/kVHctoNPlxY54/rTGSTpkWryxjyzfComc/eBL/USuguO+6XpUBeRJ1OmBIOfzmY331MVDgHkYucO0BcMjJGuzpP6QB13tJqtxiMWJj5tor+wcjl31e+4pCHrxFLYl805fS/kfKbVQa+ihF9K+kIkW4GbAsl1WVRZPCPzTBNxWFoxp1uXAliWApn5rkpC571g6hJIqAtIAZ025OvEF0bDMVxzC4MiYRbaJyd9ZvwtFRklb9alTkY8ssXtuhkiCGOLnAWNxSVmyNluA/u/5ftnx69SHFKznLlLE8Q3MJLE/FaMaF66EK62LpvrM6S+X5yDRzvRF5Q89XP3QwoID3Qmfqrd4ogDduFvbX9gfOAnTsiSce8t09o2KeLcZ0XS3KAda66Dj8fY1bQZHLmIQVI17MQJQplxvc+VN7EVSCWZ7Js24VxyVV37AzBEr7uDZ7wL9HYqEtly/zE/AxMuugtoX+RPXYvodY8ImOcjYgdn93ZJUYXrxjq066AW8XLmA2txbGxemNN0WvF03rDVHDCm1lGjlT3WcJvKt2iN0CDXMoxleKdjVfLe+Y3lWQ+MUuW+8jZY8UT02x5uEYR7f+49Abx/iXbTa/TgcsxBjX/d6JLo32eiDyi7IjilwfOf9XluCPFsyFbH1l0im8bL90I8m1yIL304kIuUEGXfgiFHxHG0TbwqVq4erEqEnwVYgTToeTY/j+kei2wjApBaG8mCbOFSfaPstL/PB+Axypy4rD1UlPa8hmmAKrWz5K8NPiEWW+Vx7Olpty3VhzafqE8iF0m0i6W7psq4A2NaovIK3KiZb5Lkur3Ff4DP8ZKVYgwi+cOTwGdBJu4Bd7hCsPGLjQYOKFEJQrzPRIBRsgbTHAbsheWsqNyxLsd30iYEyptN0Yco9leUfLJhzkxjemUno2Vl2EDzxc1IkF2m9ksHTv650RRVUe72TFbclglsU5Us i2zDl+ci IwEQYFSsIhs7N4Vr5RnfJnP9tPHXzwfDKYuWmsye8rM8b545J1UBY+CERPFIz2I5EJxYiKE3PZzObf04VrDD7i8U5BIDOxJlvPrxmpXdLSAMFpHT2xhEPHyFAQ6FNJQUCY9xSA47FfJVw7Jzw5apmny1sV8MADPXIdZORP26wgvo2ODkTGbn93UOZtjsRVovZNiKVCMtifeFX/UR/QNIDnFReDAFL3S4KqCXcOAGyGLtl8i1iJYacrUA3HEKIyVuVX1wSKF6ml5eIoMpiMGe2V+dKjquNi54YdDc0jVf22tgIKZo= 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 11:34=E2=80=AFPM Yin, Fengwei wrote: > > > > On 7/8/2023 1:11 PM, Yu Zhao wrote: > > 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 *f= olio, > >> * still be set while VM_SPECIAL bits are added: so ignore = it then. > >> */ > >> if (unlikely((vma->vm_flags & (VM_LOCKED|VM_SPECIAL)) =3D=3D V= M_LOCKED) && > >> - (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 f= rom VMA > >> + * piece by piece, allow munlock the large folio which is part= ially > >> + * 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 *fol= io, > >> 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. > Good point. We can't bail out here as return here means folio should > not be reclaimed. My understanding is that we should skip the entries > which is in the range of VM_LOCKED VMA. Will address this in coming > version. Thanks. Yes, that's what I mean. A wrapper would be cleaner: while () { ... if (vma->vm_flags & VM_LOCKED) { if (cant_mlock()) goto next; ... return false; } ... next: pra->mapcount--; }