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 379BFC3DA4A for ; Sun, 11 Aug 2024 05:20:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07EBC6B008A; Sun, 11 Aug 2024 01:20:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 02CF26B0092; Sun, 11 Aug 2024 01:20:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E36AF6B0095; Sun, 11 Aug 2024 01:20:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id C5CA46B008A for ; Sun, 11 Aug 2024 01:20:52 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 38AEDA87D8 for ; Sun, 11 Aug 2024 05:20:52 +0000 (UTC) X-FDA: 82438815144.27.B4824B0 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf03.hostedemail.com (Postfix) with ESMTP id 7BE6A20015 for ; Sun, 11 Aug 2024 05:20:49 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RNABIpGD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723353599; a=rsa-sha256; cv=none; b=s5cJ4OCipl/x/Bs/2qhcaz89z3QPhlYWaItNX1OtgGNpc28pdQzdNHYRP4WXidpSWPQxkw BYN30F170CJ+FlAqXpF1Kd6ifJzy7QFdoZgj9JecQc2fvRB/rO2WQmCw7+CeA3xKgU6E6C 2htVRxnJc3M9VIn4mnXwIdO/C3ekzEk= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RNABIpGD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 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=1723353599; 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=RevC54WGHITOMl6WLV6J8Ojm15LinFzCuYl4UNPBWi8=; b=fpvPfaMxyBftIFG00OdqMthIOLSTdrrRVRXMRg0Bvbo6/wz7/xqVxJVeAzBqqRPHwnNMl8 sShJi78DBPun1Gz0Db4zWl0I3uHUnYbxM+O2Qg/Zz3KBYwPiRGXp2lPIGrfwauqwQZTRtE iXQsYFdwLR0p750x8YDs7Vwpch0ULRQ= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-4928fb6fdceso1135146137.3 for ; Sat, 10 Aug 2024 22:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723353648; x=1723958448; 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=RevC54WGHITOMl6WLV6J8Ojm15LinFzCuYl4UNPBWi8=; b=RNABIpGDDmdEY6M0t2T26a4f+Zn4zJ39ISmmPYcXlziUag2FZjeb+UjcktXNglRMzp bsVgyRgRxwIFO9dFI6eFgZ0e6LT3phZVWPtyYmEbbuaf3IfsOMaPXfioM10p9qp30UiA L27WiJi2UrupFc/a4Sve1jFMzhX8A9kpl72PLdjp98Zk4W8aVpBFV4BSVqIYr4RHIB1w AneEXyhPFMiQhoAB2pukZK7d5QR03YB5pcCAQ204DuYw6A8+XbbgcQA90OTSVMRUS5uL Hgvy1F9F1rm6cicSxcd7npKCB4LJ8lvxHZWZj7mw2ZmJFAMgNk0mEUvQf24+39bsYvL2 XQBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723353648; x=1723958448; 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=RevC54WGHITOMl6WLV6J8Ojm15LinFzCuYl4UNPBWi8=; b=kwBILuiu8fjyXU9jmzqKoErmJOWSLdGadrqK+HtTszrQ9t55kI2w03FCRn8NQ2hZDH TR0nV+6wMYNkdi37AkE3VA80DdS5fuAFZPT8HIHmQGPnsFRyX9kbg9AuWcPUSFmvZTpf HMWW/IZGJkwA01oIQ0u7dm6GBQboDQ99jUjagwFqc2XvsNmf2LyaZFD/mFUwRMAKgYEL QOFqIsTwXNQrnmZbd9qyQrsDZhuxakaAF4CEicqlCsCktFEYjEAiyAbfK8STFtDYX0tE FeoIZUUjIxjw88ZHxYgQ0Kr6/l8GAwWnZFTvK2YrX6H6Ef92jzIK/rCBZ+RE5BJK3Mx/ OtKA== X-Forwarded-Encrypted: i=1; AJvYcCWoWf40I4cDBZJcdO3cR8w5wH/LnkQeOWO5AXm06A+YVo0ByLqRqva08Rc01OJHNdgyExP8ZVh9S2XOAeSqhRedylY= X-Gm-Message-State: AOJu0YxL/ROqlZ4Zhs8qkkP3Qmy4SBcEuAXwvEY1sHi/YwHMcWZ7G8E4 VyNSuoY14TgbOxQIl9F4Jh9ok5iWiej6Qu9+t40OFgZLxPrX354twSK4xg315qF8CFYlZfZsmd/ LJZbnLSpr/PVn/3CEIYi2ztsoWDI= X-Google-Smtp-Source: AGHT+IGkeQaUTtML4BAUSknZ/hBerb+DXBKsTJxJ9HJGdHKaCjW0i004NcOl8UENx+Mx7weGwmwsaIpcn7zI/0kuIRQ= X-Received: by 2002:a05:6102:3588:b0:48f:e5d1:241d with SMTP id ada2fe7eead31-495d84855e9mr7514227137.14.1723353648360; Sat, 10 Aug 2024 22:20:48 -0700 (PDT) MIME-Version: 1.0 References: <41b49313-5804-46ba-9e1d-358b079274cd@redhat.com> <20240809070412.33847-1-21cnbao@gmail.com> <62d758b1-595a-4c05-ab89-3fe43d79f1bf@redhat.com> In-Reply-To: <62d758b1-595a-4c05-ab89-3fe43d79f1bf@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Sun, 11 Aug 2024 17:20:37 +1200 Message-ID: Subject: Re: [PATCH RFC 1/2] mm: collect the number of anon large folios To: David Hildenbrand Cc: akpm@linux-foundation.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, hanchuanhua@oppo.com, ioworker0@gmail.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ryan.roberts@arm.com, v-songbaohua@oppo.com, ziy@nvidia.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7BE6A20015 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xidbpbyd4mzqq8ctsfjnc5qt3opbzsb4 X-HE-Tag: 1723353649-418620 X-HE-Meta: U2FsdGVkX18dU83m5dfRqrHiHtBeVAQTYEFnnDwAeolE+gpvdNulGRJfcpAuHOGTZ3IQOWFJMqOvASnBx2AaldscIG4BSzCFLj0zFzFvJZ465zCN2NpPoqrQAg5AkQvFkFLoMUhuQQjLjfwSkEXHfpO6Yb1xcskbXw6VFqt88FmASz9kA8klgxOvjKEv4uYQjEYw6NCuNnz+MzW2abuxGlNGzpQAA/vI6D2bFfcQqNN0wxTfp6mkJUsBHVlA31/APN8kNzG3nofLLs2bBlkcAD73BAjRVz/J78RJ3Yltcy8/x3rwr0h3+zI3nC5dUPNz0MGtAwO+JLFdnQwqQV44xeStFmlQ+rEjbhWwK2z1OcgArf5fnjNrzJYweenQoHd5HT4MiPufoarpnTPuyjYA3XjLN3lmnG4tPimOc26yCRPQHlkkPXi8CT63TCH71YkFzrD65kyhMg91768YlchnkwPbSoTC2FQCzlKap/Rw9XLvFA/HiRIX+YojDhfmSRfB9FdLP69HIjrSgWbf2vzcJZzxeJAxFjO1YgLaZIgT3zjKwd1PXAAz91KP+I4hWhyAo8HJcFkBOgpzZAOgzngZ7/UFWCdcHjBAN1HHuGApcpkBSmLs40z7+ztG5V4YdD3u/lrusXCAMmBEVL92EGIvWJLFNjf86L+fKvShenjcWg4KwGbTUTl38XqcSD9SggTAiWx07iJhqUMIqzTNmhdBKO+LLkJXxiRNzZjCFkbdeMjDsJ2c+V+zw03HK8pOc6DT645quEJki/czA7UJ/hyQOsD5I6leCujHlLM/pQL+9PXGBk1aAaMxF5+IGC3NEeTV0WE1cBCyPJl5ltfWnmjI1gTe4IA/bl/oYJPiK/oNvqWDWD+g9f99hD2wSNEa15mvCq3/TKuc5y1CiV7V73h3pNU5yIP02diC0UwyNX6u9v8pwYTN7AH5jNnkNcGEQOuDbEBpTgGQz94x5HfJK15 SdRArx8m I5sOC8QVPq90ire62G9mu5ktapV5K4ZdVArGWKRxxH1wGH650a4DmGjkDPq2p5mI9E7pMqHdP34UQcw29pe7SejunlmBlnhY3tjBE5cBLH5Lo0qgRND0jzOxafuQXhuZ4WsYW7uxd3rGeR61rANsIvPyPBtRXznoi8g6hNmqVSO5lkIqMgtUDoYhA55HttT76/lR6rNz1D7Zy/S/He33dQFeC4n7OAVRfJpZl/H6ejjdrrOmZZE8dzBTorqzlyQd6tA9WR2r0TA0QVXk3xhEePbjyXoUBQ65AvuxrB6FPY/dCw0baBa5pXegoenFGggtIsO+S 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 Fri, Aug 9, 2024 at 7:22=E2=80=AFPM David Hildenbrand = wrote: > > On 09.08.24 09:04, Barry Song wrote: > >>>> I would appreciate if we leave the rmap out here. > >>>> > >>>> Can't we handle that when actually freeing the folio? folio_test_ano= n() > >>>> is sticky until freed. > >>> > >>> To be clearer: we increment the counter when we set a folio anon, whi= ch > >>> should indeed only happen in folio_add_new_anon_rmap(). We'll have to > >>> ignore hugetlb here where we do it in hugetlb_add_new_anon_rmap(). > >>> > >>> Then, when we free an anon folio we decrement the counter. (hugetlb > >>> should clear the anon flag when an anon folio gets freed back to its > >>> allocator -- likely that is already done). > >>> > >> > >> Sorry that I am talking to myself: I'm wondering if we also have to > >> adjust the counter when splitting a large folio to multiple > >> smaller-but-still-large folios. > > > > Hi David, > > > > The conceptual code is shown below. Does this make more > > sense to you? we have a line "mod_mthp_stat(new_order, > > MTHP_STAT_NR_ANON, 1 << (order - new_order));" > > > > @@ -3270,8 +3272,9 @@ int split_huge_page_to_list_to_order(struct page = *page, struct list_head *list, > > struct deferred_split *ds_queue =3D get_deferred_split_queue(foli= o); > > /* reset xarray order to new order after split */ > > XA_STATE_ORDER(xas, &folio->mapping->i_pages, folio->index, new_o= rder); > > - struct anon_vma *anon_vma =3D NULL; > > + bool is_anon =3D folio_test_anon(folio); > > struct address_space *mapping =3D NULL; > > + struct anon_vma *anon_vma =3D NULL; > > int order =3D folio_order(folio); > > int extra_pins, ret; > > pgoff_t end; > > @@ -3283,7 +3286,7 @@ int split_huge_page_to_list_to_order(struct page = *page, struct list_head *list, > > if (new_order >=3D folio_order(folio)) > > return -EINVAL; > > > > - if (folio_test_anon(folio)) { > > + if (is_anon) { > > /* order-1 is not supported for anonymous THP. */ > > if (new_order =3D=3D 1) { > > VM_WARN_ONCE(1, "Cannot split to order-1 folio"); > > @@ -3323,7 +3326,7 @@ int split_huge_page_to_list_to_order(struct page = *page, struct list_head *list, > > if (folio_test_writeback(folio)) > > return -EBUSY; > > > > - if (folio_test_anon(folio)) { > > + if (is_anon) { > > /* > > * The caller does not necessarily hold an mmap_lock that= would > > * prevent the anon_vma disappearing so we first we take = a > > @@ -3437,6 +3440,10 @@ int split_huge_page_to_list_to_order(struct page= *page, struct list_head *list, > > } > > } > > > > + if (is_anon) { > > + mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); > > + mod_mthp_stat(new_order, MTHP_STAT_NR_ANON, 1 << = (order - new_order)); > > + } > > __split_huge_page(page, list, end, new_order); > > ret =3D 0; > > } else { > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 408ef3d25cf5..c869d0601614 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1039,6 +1039,7 @@ __always_inline bool free_pages_prepare(struct pa= ge *page, > > bool skip_kasan_poison =3D should_skip_kasan_poison(page); > > bool init =3D want_init_on_free(); > > bool compound =3D PageCompound(page); > > + bool anon =3D PageAnon(page); > > > > VM_BUG_ON_PAGE(PageTail(page), page); > > > > @@ -1130,6 +1131,9 @@ __always_inline bool free_pages_prepare(struct pa= ge *page, > > > > debug_pagealloc_unmap_pages(page, 1 << order); > > > > + if (anon && compound) > > + mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); > > + > > return true; > > I'd have placed it here, when we are already passed the "PageMappingFlags= " check and > shouldn't have any added overhead for most !anon pages IIRC (mostly only = anon/ksm pages should > run into that path). > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 408ef3d25cf5..a11b9dd62964 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1079,8 +1079,11 @@ __always_inline bool free_pages_prepare(struct pag= e *page, > (page + i)->flags &=3D ~PAGE_FLAGS_CHECK_AT_PREP= ; > } > } > - if (PageMappingFlags(page)) > + if (PageMappingFlags(page)) { > + if (PageAnon(page) && compound) > + mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); > page->mapping =3D NULL; > + } > if (is_check_pages_enabled()) { > if (free_page_is_bad(page)) > bad++; > This looks better, but we're not concerned about the bad pages, correct? For bad pages, we're reducing the count by 1, but they aren't actually freed. We don't need to worry about this since it's already considered a bug, right? > Conceptually LGTM. We account an anon folio as long as it's anon, > even when still GUP-pinned after unmapping it or when temporarily > unmapping+remapping it during migration. right. but migration might be a problem? as the dst folio doesn't call folio_add_new_anon_rmap(), dst->mapping is copied from src. So I suspect we need the below (otherwise, src has been put and got -1, but dst won't get +1), diff --git a/mm/migrate.c b/mm/migrate.c index 7e1267042a56..11ef11e59036 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1102,6 +1102,8 @@ static void migrate_folio_done(struct folio *src, mod_node_page_state(folio_pgdat(src), NR_ISOLATED_ANON + folio_is_file_lru(src), -folio_nr_pages(src)); + mod_mthp_stat(folio_order(src), MTHP_STAT_NR_ANON, 1); + if (reason !=3D MR_MEMORY_FAILURE) /* We release the page in page_handle_poison. */ folio_put(src); > > -- > Cheers, > > David / dhildenb > Thanks Barry