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 B2587CA0FE1 for ; Fri, 1 Sep 2023 04:27:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 158918D0017; Fri, 1 Sep 2023 00:27:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 109418D0002; Fri, 1 Sep 2023 00:27:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F3A7F8D0017; Fri, 1 Sep 2023 00:27:04 -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 E62CF8D0002 for ; Fri, 1 Sep 2023 00:27:04 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id A4726160109 for ; Fri, 1 Sep 2023 04:27:04 +0000 (UTC) X-FDA: 81186743568.13.1788D87 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf10.hostedemail.com (Postfix) with ESMTP id 07845C000F for ; Fri, 1 Sep 2023 04:27:02 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Nqw77fVu; spf=none (imf10.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=1693542423; 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=WITYMfsKljW+lUKD+hRzcRJ2K96ZtkDKJ+opWiQ9Fqw=; b=ToxK/O012gNUu62OeAS6bzbxX1iR3+h2pdBXpWVdWw3VAIRYfOq4kx5GVgZzA2rdz11CbV 4Ej5EFHsmp7AMNP8GNbO7eC4f6IUv9EzmawebGbYWkLiRzZiKPxCWTziXuOv9NOFUy9zXW uxlnuYISiI7KHyIBRI3nQoeD4hvJMQg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693542423; a=rsa-sha256; cv=none; b=OdYgdw5OZJb5vLGSURi+3vmMZsjhbf2pONSqAd/65YPykrf+jNcF0PyP+Aj0VOMjjAF2Ul hCqvdkRlxy6zflOJ5JrAktAU4t3Jf0aJaOk8ne3GphbtBDot59T99qAJG+o00pCebJ4cE0 K8Y9axKhh77trFNkLc5SDh4/GYypbtc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Nqw77fVu; spf=none (imf10.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=WITYMfsKljW+lUKD+hRzcRJ2K96ZtkDKJ+opWiQ9Fqw=; b=Nqw77fVuNxvM9Mk6p8ECcjZ7Gp SFX5vY3j24IDzSjs8obnl6LMu9IELe2SrlarJc45C3U0YL8SRtreNeMTnG5jVw1JEwR3wAdNBVxw1 r9TVmZjzlmg0Rd8xQBT7TVzLAQ+8mMl9hhf2++9P77qXTdF1eHOc6izSVAXRbHigaMoxUAciA6nRU AmG0HEGTjwhbNhOsi7+Iu9AmavVRJMPAvmhJcDrjiVDT1GwPlGgexlL+Nzj3v2Ah/oUNxj2BIWGrC XslVqCsfa3abRZdo+uWIcc6tO7QdpIouxux7izWNxo4APTIbSKARB4zTqWLyuGTGHuagWDTlsMv3J MNylJTnA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qbvkL-005PRr-6p; Fri, 01 Sep 2023 04:27:01 +0000 Date: Fri, 1 Sep 2023 05:27:01 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: linux-mm@kvack.org Subject: Re: [RFC PATCH 18/18] mm: Add pfn_range_put() Message-ID: References: <20230825135918.4164671-1-willy@infradead.org> <20230830185041.3427464-4-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: qs1jwzbjo34sjdjz7jfe9xzxnw8k4pqy X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 07845C000F X-Rspam-User: X-HE-Tag: 1693542422-123031 X-HE-Meta: U2FsdGVkX18Br/08UFRVmxvnKLOcl7MVgr5QVWG5WbmvXEMOTho23eshi22ej+f6S7gIuV1AOV04sx8kQyUTF+Ci54QTDNoW1GMlBZGMka95Rl1OhbXuEYLt2ueIr9CVhvWUhiVv4aCM7xG9zKmSxbj4H4bRPGEnryhtj2Dq9rUSATWTcCEjYzBFRyUegydLxwrJA8ERk70FrwqxXAYO0X9O9/hmKozGDNWjwWviRttfMkemLZl8tyYDULp6dcmv6VRjsmUjT8m6hHfk8fjZJ/UYXoeSMJo8Rdj7mxxp3zX8lsIHxD69j7tbhwBelzW6TNmcx45pJu9J6taAalLe5LIYqRdxnJ8IsCzevjgRkfEbKPxjveH9naxCRa7SiiLT00dWJXBPPttepi2wU9bLpwfTcIUo3VYznUFXKmK+zEU0M38gaf2TL7FKTeqdD2SKIQOZE7eQdKZMX9hiNy3elYlbElTeCZtJpOb1qDLAGk2UEB8MGiQiid3PKreTzl7tOgE8bIzOsyGRyXVAOm62yiT/6btSet2rrXrq7BuYdPteTIftuiB2FsiWcHTuCfddYJKpX2d1Wn6WeMU3hU+InT6kSn2SOqgUHfftU4TI5MtR6zxfUHpr0VOIv0219r9/oHIkpFjihrRdF8LKCWK2K5rOa025ky4icgJ/7/eCxwX9HeIVvV6DAObSJTS987amRA+Rf/ePShuZ3lRMdprcSVAIMxdTRMqfyi60SK6r8CbxYUDfwWYyYxuBp/h5ljZGHwEfNlMBVxdiSt/VI9JKsTEDFMfGt1rVb1PI0wgouvN80qmt7aEl24NZphBAsT1c7IaQR0t6WwTvj4qkCfTr1t070gs+BOxfuhGHlYJONBtaAX+bCE9/JK/0TEHy2HpGiYmurF8GJ2YabZFi4AhTm6B3toPpeN89+9AblWjbLaSnvoxQt7Bngj9SXva0a6NoWxcqmojJq15p8ovQuo8 2wmXxg9R PoBWpkM+YDKpbByP7GRgJHaX8KFVjLANT4/PxYnqFDg9JCXmnGX+LMhNxLLyw1J/efGWFuzsC8P5SZOC79aAj1phMQY+Ev5vR/+2S4eSYDITP9Ni7hQk5X/bnO+SlW7NgSwhQRN2Dt9QOvI9dUJ0EhvOltl+UT0Ix8O3yf9lwzOU/R46R7uOvlqZL+A== 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 Thu, Aug 31, 2023 at 08:03:14PM +0100, Ryan Roberts wrote: > > +++ b/include/linux/mm.h > > @@ -1515,6 +1515,13 @@ typedef union { > > void release_pages(release_pages_arg, int nr); > > void folios_put(struct folio_batch *folios); > > > > +struct pfn_range { > > + unsigned long start; > > + unsigned long end; > > +}; > > As mentioned in the other thread, I think we need to better convey that a > pfn_range must be fully contained within a single folio. Perhaps its better to > call it `struct folio_region`? Yep, I'm not taking a strong position on that. We can call it whatever you like, subject to usual nitpicking later. > > + > > +void pfn_range_put(struct pfn_range *range, unsigned int nr); > > If going with `struct folio_region`, we could call this folios_put_refs()? > > Or if you hate that idea and want to stick with pfn, then at least call it > pfn_ranges_put() (with s on ranges). folio_regions_put()? I don't know at this point; nothing's speaking to me. > > +void pfn_range_put(struct pfn_range *range, unsigned int nr) > > +{ > > + struct folio_batch folios; > > + unsigned int i; > > + struct lruvec *lruvec = NULL; > > + unsigned long flags = 0; > > + > > + folio_batch_init(&folios); > > + for (i = 0; i < nr; i++) { > > + struct folio *folio = pfn_folio(range[i].start); > > + unsigned int refs = range[i].end - range[i].start; > > Don't you need to check for huge zero page like in folios_put()? > > if (is_huge_zero_page(&folio->page)) > continue; Maybe? Can we put the huge zero page in here, or would we filter it out earlier? > > + if (lruvec) > > + unlock_page_lruvec_irqrestore(lruvec, flags); > > + > > + if (folios.nr) { > > + mem_cgroup_uncharge_folios(&folios); > > + free_unref_folios(&folios); > > + } > > +} > > This still duplicates a lot of the logic in folios_put(), but I see you have an > idea in the other thread for improving this situation - I'll reply in the > context of that thread. > > But overall this looks great - thanks for taking the time to put this together - > it will integrate nicely with my mmugather series. > Thanks! One thing I was wondering; intended to look at today, but didn't have time for it -- can we use mmugather to solve how vmscan wants to handle batched TLB IPIs for mapped pages, instead of having its own thing? 72b252aed506 is the commit to look at.