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 D801AC5475B for ; Fri, 8 Mar 2024 17:13:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 534DA6B03C3; Fri, 8 Mar 2024 12:13:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E3EB6B03C7; Fri, 8 Mar 2024 12:13:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D34A6B03C9; Fri, 8 Mar 2024 12:13:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2D0146B03C3 for ; Fri, 8 Mar 2024 12:13:38 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E261A806E8 for ; Fri, 8 Mar 2024 17:13:37 +0000 (UTC) X-FDA: 81874518474.19.92C38EF Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 180198000A for ; Fri, 8 Mar 2024 17:13:34 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709918015; 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; bh=XKMEvUCSGlXPMcR98+SF5S5Xw32xbEuhIasTDgJueag=; b=kBNRsQ8SZvX4qqSK6Swt3a1HDSW6aAhuU/FOvBN08PHSqm84QUqdB1ESTaw7VbJUwclhwx UzJwnFCJS8b9xg/Rt1R5X2JxGfkrdyEqk8ifNMuEohqlG6ruLKXaT9PhpZfDTYiosub4MZ m/F+kdfjLTPMc8Tj5r3RaRdwpeJ39Gk= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709918015; a=rsa-sha256; cv=none; b=oy4kiFvxaMH4PmGMNvCvCOjvv7Zp2ENyHN4MJ1G0DZ0iY5Ee05CS+eTEJgtOl4gOXG25hf jtihW4SReX4NY74qtKjZH/sCmZqyVOr7Zw1QQXBDHmWFa3c7p4ycBxiegcPgYRspvsBHZM o4sdw0EVCCWCylMvSTg/MHyETyFsKpc= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 13810C15; Fri, 8 Mar 2024 09:14:09 -0800 (PST) Received: from [10.57.70.163] (unknown [10.57.70.163]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0AB593F738; Fri, 8 Mar 2024 09:13:30 -0800 (PST) Message-ID: Date: Fri, 8 Mar 2024 17:13:28 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 10/18] mm: Allow non-hugetlb large folios to be batch processed Content-Language: en-GB To: Matthew Wilcox , David Hildenbrand Cc: Zi Yan , Andrew Morton , linux-mm@kvack.org, Yang Shi , Huang Ying References: <36bdda72-2731-440e-ad15-39b845401f50@arm.com> <03CE3A00-917C-48CC-8E1C-6A98713C817C@nvidia.com> <7415b36c-b5d3-4655-92e1-b303104bf4a9@arm.com> <644c2f60-dbb0-4fdb-8505-96f8101b2399@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 180198000A X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: n57fcmu4cwz51m5y3bkyf5qpobse8pyx X-HE-Tag: 1709918014-266253 X-HE-Meta: U2FsdGVkX1+NnHnP3M2rurkjJNuBswTXagetrERK4NqzfowROAsGZoJU4zGhcMSWOLPZXUo/YuVekfbxAw1uR2HPIVKMOPm/z4DssgEWsJPIaU+HbBTDAnydHQuvUjbOTjzObc0OQy6gjNZXhrCaWOdutIYAdZhBpBZK8zwcmAT9OlSRkc8XncJisBRjb1NjqQmMPA2FXnfDzPVhhuJkcTkVXjzq0Wm1mtO+ZJnR00vwVdXG2D9gIRLRu5OQHDnZTRm6jBmAn4O6EhyGOqp9lB7x3hnWG4uBSLQJgT/1Hp5YOV3aL2Lc1BAwSrdWHUSU3KOlHdShKoqVT0FWfl1grpJ6aVTONw32lhEyzKtzD5dfY2b5u0TihRL58tT7LwXqoecxpu09cyIvJkR3a6OjGrcqLfa/VDKQ1ACbe9CvURrhgdBPNMp2lSIVDFHJgDGltJUKrN4oxz17dl20r5b1wqDk6Bk3dEMlsHWt3w3nuuTZfoaeAZCHB2cMsx4mjACiLQjQFqJcB2GUGx1UjmVL829clSoThxOlmDCZ9YEi4Rq1xTKc8DhUc4Xdv5KRS5MNUd3b65uK4SKIng0TGdb/R2lDSt2/TKajNIzenDMTU5t9PCKUGH2ZUoXBOBTUHCSCbFA8UOOmqWPQ52ZDa1d0wnxi1OOMJPsTrbRdiT8Spk8XFi3QrYx8Qs1sVnpFv/pZrKAS7G0gTt+0hQrCQORC+4F9m6fCYtW7+d7EfLfbz+K9Ll7wd2hXRC/MMnKwziMjKMbn2ahA5MOA1MRn423sTmXaQHYX7S5Qk+te2gKEiVETcKJrKAuSCVlcNNRXhwnlLqaai+DtTPrZsfy5xDRuTxts4JSq4ZHJ3e01j5Dq6TNdCXljl7L1nziued4OT+PIELUpWI5kXGtFOqDjFW9AlS95+7RBe2oJnGJIMn+sFAuG6H8/uPO5q3G29yZU7H+8SohXM/uc1UOO5argI8X wLL6sdlU ak33qV0U1Qq5llYcAGbB/X2yKUdzXl1gGOwXXRPvXVwxOIwAqI4giWfCCwTK59E456xlK2l9CMu6y+BxN3IpIRYFKpfwqpPrZGwr3uMW12pdFto0F/8ITFkwO+rDO424at01ROXEHvQKs7cVu1+iQgkciUA== 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: + DavidH On 08/03/2024 16:03, Matthew Wilcox wrote: > On Fri, Mar 08, 2024 at 03:11:35PM +0000, Matthew Wilcox wrote: >> Actually, I have a clue! The third and fourth word have the same value. >> That's indicative of an empty list_head. And if this were LRU, that would >> be the second and third word. And the PFN is congruent to 2 modulo 4. >> So this is the second tail page, and that's an empty deferred_list. >> So how do we init a list_head after a folio gets freed? > > We should probably add this patch anyway, because why wouldn't we want > to check this. Maybe it'll catch your offender? > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 025ad1a7df7b..fc9c7ca24c4c 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1007,9 +1007,12 @@ static int free_tail_page_prepare(struct page *head_page, struct page *page) > break; > case 2: > /* > - * the second tail page: ->mapping is > - * deferred_list.next -- ignore value. > + * the second tail page: ->mapping is deferred_list.next > */ > + if (unlikely(!list_empty(&folio->_deferred_list))) { > + bad_page(page, "still on deferred list"); > + goto out; > + } > break; > default: > if (page->mapping != TAIL_MAPPING) { > > (thinking about it, this may not be right for all tail pages; will Slab > stumble over this? It doesn't seem to stumble on _entire_mapcount, but > then we always initialise _entire_mapcount for all compound pages > and we don't initialise _deferred_list for slab ... gah) Yeah I'm getting a huge number of hits for this check. Most either have kfree() or free_slab() or page_to_skb() (networking code?) in the stack. Ideally need to filter on anon pages only, but presumably we have already ditched that info? Actually looks like the head page hasn't been nuked yet so should be able to test the low bit of mapping... let me have a play.