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 ECEB6C54E4A for ; Thu, 7 Mar 2024 23:02:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7C7806B02D9; Thu, 7 Mar 2024 18:02:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 778016B02DA; Thu, 7 Mar 2024 18:02:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 667416B02DB; Thu, 7 Mar 2024 18:02:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 544396B02D9 for ; Thu, 7 Mar 2024 18:02:54 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 1920914075D for ; Thu, 7 Mar 2024 23:02:54 +0000 (UTC) X-FDA: 81871769868.06.ED294A7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id A1B9012001A for ; Thu, 7 Mar 2024 23:02:49 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=DY2ZrBY1; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709852572; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WKm77Assg6F7bhZBWlzArL+gVD/SXqDQV0mDePXd5lQ=; b=VKF8AdEP/R56lw1FmlKn1C3u6o8erEj5daR02ACzfexXYgsDYuKZBEz2lCCtKM/I0/jznB Po9YPM3ArnGP6mdHVX5NV+1fuZm0ByI6LcYCbOjPwNuxBK0AlqV7fF+VQbVi2n0wCugpRJ 6YeqV2INbBO+djMNHbIY2Ln4pha6/Oo= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=DY2ZrBY1; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709852572; a=rsa-sha256; cv=none; b=oz/SGdvwSVPoe9QsmQXOyTgOeDiThUopABJWed2UMv/aDFIArrCfCxZqdDup3DubYmq++1 Zzqo9QrRrUARh+ZYgCQLBj6zkwyJTy96Mb6V2RFsOaf53nbnch/WP1xbDluL2tkiFBGeVh rTupmZEWPBQQpK4Y21k63ympQF1iCh4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=WKm77Assg6F7bhZBWlzArL+gVD/SXqDQV0mDePXd5lQ=; b=DY2ZrBY1PdhU01+EAeLASHY/R0 ao9BYrfAVSyau2OPeGOIViANxAfPWMPlREYHkdoUi4Ww1UH+xAhSsP3mIToBtId82E5na0mq6EEdu zQdXcyGxT7k2LBBvdj9tm9/3rkF8FiCse4Pke4e8K9+zRc4sYvjDJl63kTEHJ8i1pqhaUBUTcvio3 jsTP6b2wS/0Xq7sUh10oySqrVzfhDOkUjOpTeR5Xl3Z5pzElLoj/Dbu6Y3aL2WA3vbjy0ZedB9SFD d7RpcE8wC6M8ddFLurJ/Q7DZQ124vkTFf4T9QdWz7++3w/+tyEC8pIWOYxuwGgimj3zla1lZA5TeO H/iqzZGg==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1riMlC-0000000AAc7-2cvK; Thu, 07 Mar 2024 23:02:46 +0000 Date: Thu, 7 Mar 2024 23:02:46 +0000 From: Matthew Wilcox To: Ryan Roberts Cc: "Yin, Fengwei" , Zi Yan , Andrew Morton , linux-mm@kvack.org, Yang Shi , Huang Ying Subject: Re: Message-ID: References: <85cc26ed-6386-4d6b-b680-1e5fba07843f@arm.com> <36bdda72-2731-440e-ad15-39b845401f50@arm.com> <03CE3A00-917C-48CC-8E1C-6A98713C817C@nvidia.com> <0f5bdbf3-725b-49c7-ba66-973b7cfc93be@intel.com> <9ed188de-648e-463a-832b-ef132da1d16e@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ed188de-648e-463a-832b-ef132da1d16e@arm.com> X-Rspamd-Queue-Id: A1B9012001A X-Rspam-User: X-Stat-Signature: w9bn6pimwpsgiuj7pr9m1sbejq9rmygk X-Rspamd-Server: rspam01 X-HE-Tag: 1709852569-296439 X-HE-Meta: U2FsdGVkX1/L3FvIioUyeNQA7gDgplkMmYIDz8Lo/hSC/a4vYI2sUhAKSSVrtT98XY7ZDS5NR0TDqbvMCcbMqP0Lp3MssPP9m2LHCvkdUgP76tvKUWj2kr4q1js2NjBF523iVP1lTTM6OrfjHGA17lkj3KEhwPYfc73ZpmtAv/pYW5aNgkTXr+5QVNSSiM784sEkx/Hi0mFfIAM8fSBR9Afw0GX2TrLoouAUD8fLq9m/H+5bsYDW8lxMVGmh67FQJN6tNnm+Na/Tv/928/XCkMurK2XlPNWSiDvCCaKQewhBcFFzFuqEnyX76LaUJL5mEO6KrTWA0CQSnKYpnv6LTFEa1GTgCzIDM2hP8DkvdxAP7UWhNk48Vvvim6ZLhhPF4bb2Pz8nb3DkE29utT71ftuCSfC39gyQOuHQTrTZ+WpK0lJb23UAHzOESQVU9XKcCC5BjUrLJR+5bQ6MpCtYlG2oOa97Id9nXQCV9bmNZYsjG7EIOgPuB6F2zZTna/yOevJCPJ39C8YlO4nLbKGNeTvPAxCpGl0L18bKoL2Txj19BbViGcGJA2/eXhPDgyA67iR8JQ4BjpB7f3aaXTUT9/432mBTNETMdCoSVOi8tldvoMeu+PS25EHG+6JUXnIF1LK8mF8hEGu0yCwDSAH0cH4Kl4m4XB0pGB3IMQ3Gu7/S77Fh9F/SB0yI5s8FgTArgrEf/EeaGoxuPrXm3XyLXtDr5ke254NbcDaYp8I6WR+lhstQXGuaSp/yDIIt++Hh50M9Sre8a3JhY/GtQc0CUDPD6lmzeF00RRjeR3/+BimZSVgAtmQc2cBBh3yZBxCOAkVntZ4y80euVSQOSpYmfbVnxpNzfbrgsoFNkb22iD439g2VJbVF9lQyu0Ji3H9z 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 Thu, Mar 07, 2024 at 04:24:43PM +0000, Ryan Roberts wrote: > > But if I run only with the deferred split fix and DO NOT revert the other > > change, everything grinds to a halt when swapping 2M pages. Sometimes with RCU > > stalls where I can't even interact on the serial port. Sometimes (more usually) > > everything just gets stuck trying to reclaim and allocate memory. And when I > > kill the jobs, I still have barely any memory in the system - about 10% what I > > would expect. (for the benefit of anyone trying to follow along, this is now understood; it was my missing folio_put() in the 'folio_trylock failed' path) > I notice that before the commit, large folios are uncharged with > __mem_cgroup_uncharge() and now they use __mem_cgroup_uncharge_folios(). > > The former has an upfront check: > > if (!folio_memcg(folio)) > return; > > I'm not exactly sure what that's checking but could the fact this is missing > after the change cause things to go wonky? Honestly, I think that's stale. uncharge_folio() checks the same thing very early on, so all it's actually saving is a test of the LRU flag. Looks like the need for it went away in 2017 with commit a9d5adeeb4b2c73c which stopped using page->lru to gather the single page onto a degenerate list. I'll try to remember to submit a patch to delete that check. By the way, something we could try to see if the problem goes away is to re-narrow the window that i widened. ie something like this: +++ b/mm/swap.c @@ -1012,6 +1012,8 @@ void folios_put_refs(struct folio_batch *folios, unsigned int *refs) free_huge_folio(folio); continue; } + if (folio_test_large(folio) && folio_test_large_rmappable(folio)) + folio_undo_large_rmappable(folio); __page_cache_release(folio, &lruvec, &flags);