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 64107C54E67 for ; Tue, 26 Mar 2024 22:04:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E5C356B0088; Tue, 26 Mar 2024 18:04:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0C166B0089; Tue, 26 Mar 2024 18:04:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CFA746B008A; Tue, 26 Mar 2024 18:04:43 -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 C0B036B0088 for ; Tue, 26 Mar 2024 18:04:43 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5BF0240717 for ; Tue, 26 Mar 2024 22:04:43 +0000 (UTC) X-FDA: 81940570446.21.40AD602 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by imf20.hostedemail.com (Postfix) with ESMTP id 66ED11C0024 for ; Tue, 26 Mar 2024 22:04:40 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B0P84fT2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711490680; 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=cf2ibnougTR001tC5MQWCKZFCMu1RmcpUnZDVA3FWTQ=; b=BUss1RxcXiZ8DRU7iPLpsKo/gG65tNlqHk2+R+ioauS+IL2VqoJcmvWhyphOR/fcvktU/R 38ThW/78RkOzkRPTcWBNKdTflENLcvmIkCo3ZagHId1fuqipHoTaXDCs2Bmb9sZCSSb7XL FzkA8MThnEqY5OoHTyo+Pqc8IRAVOB4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=B0P84fT2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.167.174 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711490680; a=rsa-sha256; cv=none; b=fb0+nLHPnfLlIJfG4WWxCeW2vOvsTk5vKYDFWnCynfhplNS/NOIhidskMIVqEH0fx/zJQk vGXPg4IBEm3Su3uKLum9ImKQgIdBAVf/B2H5JOeB+/OsJbJq6MDEI/uVM5z8bvaVpDowPz +8YgmhjEWVPd6hVuw/mneDquZ6C37XU= Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3c3bc867eaaso2617789b6e.1 for ; Tue, 26 Mar 2024 15:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711490679; x=1712095479; darn=kvack.org; 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=cf2ibnougTR001tC5MQWCKZFCMu1RmcpUnZDVA3FWTQ=; b=B0P84fT2H804ZJRVGXRV8y/w3R6PawV2Y2b2IgI6Rqli2xcGCIUNU8jcCcRp7RFIbP i/h/8yP9lOxbrkyWf487vIjEiDL6xNsMvd27hJxNYjOyP8ME/rg6g6hyb7tX2uIqo2xe vLgUUzBDXhy2qfr1GRECHw3uDptlS01WDBDYOFkP04DFmCghuWZ7HFKepFEKUjjqcjDG 8xSLVY32agMHx22IjOpMcVDHsKfuDvv0m2TbqmqOExGTCaxGh1p+3A9h4coMWJyQWwSX 9hn827CqEMROtxQCc178CF6ARpq96xAiDLHJE+jxSEaN6Q9/voo7MZ2ZdoX2DVGxUY2P RH9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711490679; x=1712095479; 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=cf2ibnougTR001tC5MQWCKZFCMu1RmcpUnZDVA3FWTQ=; b=XFeoPFHwJ02MmpC4HzH+5c2ZQdte5+W84xP6xxyPBLMuaPvwS3DMHJTEeA7WgqMlhf 9hK7MjjKgbxsU8wpp+9Q1JUVUqIkl9O3XvrlnprPRLPTBoVTPr3fyNQN5AhiPYyx+ILL ifwT2qoBUVudsgQQ0Fakei6yB9BsU16Vh/LvPVSfo39W1Aj+2oaNJeNcKPD48voS1dm4 gw914J2gzYmLonP693+UB5qFNN0ZTHMeqIwZwLGnGra6+OH4j7Vb1wv3J8WLLDcMVHW6 uIr97b4N5uVIbi/Xy0tFPmHSjJVrD3ZzMhpcuv1LFLhCOMXK1yenCRmdsJT5z6kJycAZ uzXA== X-Forwarded-Encrypted: i=1; AJvYcCUOsOYU98Tj0w3fOE1qdllaxzpjihGhMGUJQ+N/xQZcHo3boIDft/L8LfchMNzSWrqmZ4Pwbb9+fUtCzAGbqBZHhes= X-Gm-Message-State: AOJu0Yw+pTckc5OfNSmb7DqpVe0QtgeWvUVX6GbzCW2bY9/qCAiVEwTy mpFLCrsUeEGjjj3cGkbgSqemeL93BjgBeynRemA6Xvqij0fmj16351NNMhHcRsPWSZgljRw/P7f MPHNVpawf/XNylK7DLX6BBS9znoQ= X-Google-Smtp-Source: AGHT+IGq4y2/FOCu1WV399yRnNG6DblJxt62YKejBUXGv2D+hCtgo/96epQ9kUwJ/qs8tXaOIGaI+ZlmQIRVYPltu1k= X-Received: by 2002:a05:6808:103:b0:3c3:ac2b:97f0 with SMTP id b3-20020a056808010300b003c3ac2b97f0mr2194011oie.13.1711490679417; Tue, 26 Mar 2024 15:04:39 -0700 (PDT) MIME-Version: 1.0 References: <20240306095219.71086-1-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Wed, 27 Mar 2024 11:04:28 +1300 Message-ID: Subject: Re: [PATCH v2] mm: hold PTL from the first PTE while reclaiming a large folio To: Ryan Roberts Cc: David Hildenbrand , akpm@linux-foundation.org, linux-mm@kvack.org, chrisl@kernel.org, hanchuanhua@oppo.com, hughd@google.com, linux-kernel@vger.kernel.org, mhocko@suse.com, shy828301@gmail.com, v-songbaohua@oppo.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 66ED11C0024 X-Stat-Signature: 6zsdgp31qsnbk14w9ayz18efzt9k834e X-HE-Tag: 1711490680-664680 X-HE-Meta: U2FsdGVkX18Pm7fwy/qqZWZLnVG7bzVHlC+hgiUaeZ77wz7+o1t+8L5DFxCl57LVDKsT+Llm6TxmMmsIReqGg46icTo3X2JL1yn6WaZRRV0/nPACvwJ3hdtmGaNXsOe9KO2NJY24y00gOA1oZ8woLgJ+BYameeuij6eUhJun4IjlcCTbhun45KU4OruJRsftMSUS/jlJiOdx9B6ztz5BxvaQzKv+0ehFVlZaQAQIhzQoaLzdEgrL2sne1+3UmSK2ulPV/32dIA9zXsB7peqhWcaaLRU70r53uidfFawR2PU6OAOO01rfaX5DI4+8ZmOZ8NgtM7XPPPEAua/PTN3sWBreP8vCGDr3UBz3UZXZD58hDF5i2vON/ye1YfPfhUlU0qm27ufRdtAl3pltopL07CWB9eoyClxs+IZSWRfA/fM2p/JA/XxcmCjjOOL/ZgGWncvFXJSVyOjkYYUzQUcyn+/w4O8EHd7ZO6fN2UQ5WLFG7I20kMhc7cq8HwUgSDvXYQSzocoRlxv1WvlJ4RiJ1Vy4oMHTT8vkFIKd7DqhEtDPaQ0NvggboH8QjkLejs9svHuy5l7CFu42k77all+qZlYSUAGtgyyp2sodysWdlQ+w+Y6FAG7DErAZKkOiClhQXcUs1KIMCCxGwS9XzBzARPAph30/yTk5ppP9aM5j0a0jCHmcsuewdk+aYrpSSBF5j5xDhE12xHs4xbM4lfrgyW3eyJSlR0HcS2PaMEcEW9Kv06Mk9qmrDlllpHozZjAQVMp2n33aZR0twCPEMzGX8N0CZIDXxxCdSTDStnVtwevH3LVT3LK+dgx8hnv2w5XRNRYLcjUlKlQRyogvHmtXmAfoesiUeiK/zRi83aAaE5dUHgmjxpPwv6o0KZHhPv77b5zbGz7Z6m6UpSptusL9FDJ9KiSFezLj2bR8erTNzEdZobNKCEDUJ25SGMx1oodcYx3MVDACctZ79KW3siX MofAJVW1 DkkLo/V6v4TSqdzTNPBYvQCXitkXo23QiLfjMee0tQhfam6wjrcoRsScWjqaPI6jQH3KF8cg+DauJr7O54pAfvWpKk2YEH5MpMFMzmTki5WZ6VMoWEL2ytVhqmTgHIy1/5ZAa7T7JLgScSL7/YgphzMAA0l4/cjDqswkLziqRflLh4gdfc7UpsBIAGqZq7dlLIG3/ddjR82K0LOYeWLLLWs1vc9uWAb9rQYwLhqyXmWAs0cNfA0RuVQ7ig56Yu0VAdHkOh/VmJgq5SFYL1d1lQfpFjlW/pvm/mHSmpzUTAINoNvt1oNiGS8H9NWz1lGC6Qe0JagTTQJYKbXqtMDxdEeamxxvOWFiZtABUosAteOwlkjyEfmGU2Y1BTsWBbS99JnMTNKEUObqfQ/eg9noU6Cp3fNU7mOr++Hmw/H33UrH8U6seVkjJTKyoqUvS8mfY0IcA0QCeibd6abxdu5TSVHoYznPdo4jZzgBSmZzYg5BDGpFmMSo0tPnzY+v2dC4ZwEFilGSpuAeRKao= 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: List-Subscribe: List-Unsubscribe: On Wed, Mar 27, 2024 at 5:17=E2=80=AFAM Ryan Roberts = wrote: > > On 26/03/2024 16:10, David Hildenbrand wrote: > > On 06.03.24 10:52, Barry Song wrote: > >> From: Barry Song > >> > >> Within try_to_unmap_one(), page_vma_mapped_walk() races with other > >> PTE modifications preceded by pte clear. While iterating over PTEs > >> of a large folio, it only starts acquiring PTL from the first valid > >> (present) PTE. PTE modifications can temporarily set PTEs to > >> pte_none. Consequently, the initial PTEs of a large folio might > >> be skipped in try_to_unmap_one(). > >> For example, for an anon folio, if we skip PTE0, we may have PTE0 > >> which is still present, while PTE1 ~ PTE(nr_pages - 1) are swap > >> entries after try_to_unmap_one(). > >> So folio will be still mapped, the folio fails to be reclaimed > >> and is put back to LRU in this round. > >> This also breaks up PTEs optimization such as CONT-PTE on this > >> large folio and may lead to accident folio_split() afterwards. > >> And since a part of PTEs are now swap entries, accessing those > >> parts will introduce overhead - do_swap_page. > >> Although the kernel can withstand all of the above issues, the > >> situation still seems quite awkward and warrants making it more > >> ideal. > >> The same race also occurs with small folios, but they have only > >> one PTE, thus, it won't be possible for them to be partially > >> unmapped. > >> This patch holds PTL from PTE0, allowing us to avoid reading PTE > >> values that are in the process of being transformed. With stable > >> PTE values, we can ensure that this large folio is either > >> completely reclaimed or that all PTEs remain untouched in this > >> round. > >> A corner case is that if we hold PTL from PTE0 and most initial > >> PTEs have been really unmapped before that, we may increase the > >> duration of holding PTL. Thus we only apply this optimization to > >> folios which are still entirely mapped (not in deferred_split > >> list). > >> > >> Cc: Hugh Dickins > >> Signed-off-by: Barry Song > >> --- > >> v2: > >> * Refine commit message and code comment after reading all comments > >> from Ryan and David, thanks! > >> * Avoid increasing the duration of PTL by applying optimization > >> on folios not in deferred_split_list with respect to Ying's > >> comment, thanks! > >> > >> mm/vmscan.c | 12 ++++++++++++ > >> 1 file changed, 12 insertions(+) > >> > >> diff --git a/mm/vmscan.c b/mm/vmscan.c > >> index 0b888a2afa58..7106741387e8 100644 > >> --- a/mm/vmscan.c > >> +++ b/mm/vmscan.c > >> @@ -1270,6 +1270,18 @@ static unsigned int shrink_folio_list(struct li= st_head > >> *folio_list, > >> if (folio_test_pmd_mappable(folio)) > >> flags |=3D TTU_SPLIT_HUGE_PMD; > >> + /* > >> + * Without TTU_SYNC, try_to_unmap will only begin to hold= PTL > >> + * from the first present PTE within a large folio. Some = initial > >> + * PTEs might be skipped due to races with parallel PTE w= rites > >> + * in which PTEs can be cleared temporarily before being = written > >> + * new present values. This will lead to a large folio is= still > >> + * mapped while some subpages have been partially unmappe= d after > >> + * try_to_unmap; TTU_SYNC helps try_to_unmap acquire PTL = from the > >> + * first PTE, eliminating the influence of temporary PTE = values. > >> + */ > >> + if (folio_test_large(folio) && list_empty(&folio->_deferr= ed_list)) > >> + flags |=3D TTU_SYNC; > >> try_to_unmap(folio, flags); > >> if (folio_mapped(folio)) { > > > > Hopefully this won't have unexpected performance "surprises". > > > > I do wonder if we should really care about the "_deferred_list" optimiz= ation > > here, though, I'd just drop it. this is for a corner case: <0, nr_pages-2> of a large folio have been unma= pped but nr_pages - 1 is still mapped. we are holding PTL to skip <0, nr_pages-2= > w/ the patch, otherwise, we are skipping those PTEs w/o PTL. But Ryan's swap-out will anyway split the folio before try_to_unmap, so I feel we can drop it. > > I also concluded that we do need the data_race() annotation around list_e= mpty() > if you do wind up keeping it. But I agree with David about dropping it. > > > > > In any case > > > > Acked-by: David Hildenbrand Thanks! > >