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 EC30FEE49AA for ; Mon, 21 Aug 2023 02:29:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ABC3900002; Sun, 20 Aug 2023 22:29:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25B4F8D0001; Sun, 20 Aug 2023 22:29:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14B4B900002; Sun, 20 Aug 2023 22:29:11 -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 068E88D0001 for ; Sun, 20 Aug 2023 22:29:11 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id C3E66160484 for ; Mon, 21 Aug 2023 02:29:10 +0000 (UTC) X-FDA: 81146529660.18.7BD82D0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id C5E4210000E for ; Mon, 21 Aug 2023 02:29:08 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uL1QVT9d; spf=none (imf05.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=1692584949; 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=4iyN5XJixW9XMMjoB8nCsjnA5CisXfjAJRdmQ4Uv0Ag=; b=K+uA9suDAdPxGKP22K5AYsAXLLEs1nwjS7XCvwtcYN5WgijJ1POm0nRYUzS7WzPqouliv6 vl0WBEcb3hrg5m2pALoII5AaDaUwiXQSaj479g+nqzPxFZAxTdH9zhBL6iczSfB3g2lBo6 I8s9NRWhLUoM2E49mxTIps6bwWLWU0c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692584949; a=rsa-sha256; cv=none; b=ugSM4KqCirbMwc6SSCeKV8aVqo/CHvNo+PHkETBFyOe1vRz5CHMqSX4WcZawwaYCD/u1BD PVuYk8sqSzeafJ+v5D5zBa7DUratYOWlvuRwoFBZ36Vx3f7ZtmKRJpI8vRp/xAO819h5ZV WDF679ruyrtXNJAhXPcIqaIy95yov3k= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=uL1QVT9d; spf=none (imf05.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=4iyN5XJixW9XMMjoB8nCsjnA5CisXfjAJRdmQ4Uv0Ag=; b=uL1QVT9dnEbMu7ZjDin2zcuQa+ Z3qsxmhBtwFWzq4ektkwJ23hUTrQqgJP8qHSo54z48uyBI7qQfBwbmXkU9gwqyuMgk9OX4x53wF7H iJtIdYgxBI+hsvoERpFCv4LwKc5BGhYS75fXW8gvIlVG/x09bV/aC2s9QbRKoLmWDtALkiEY6rZS3 ium4AHlX7NYAKdmRuGQ0g21pxxwoYgmdlA+xsb366PAergxxIkh4Sc5E8mf7RzAmpotda81Gof6Uc U6ZqhDaJ8LtplJ3hWJNxPUPZM1RVLwkLoj7XzwJxj1b9ySyeH9GcQP9jdIkYcQyX4dcbOj40Z7IO6 jOTW5nPQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qXuf7-007bBg-5I; Mon, 21 Aug 2023 02:29:01 +0000 Date: Mon, 21 Aug 2023 03:29:01 +0100 From: Matthew Wilcox To: Peter Xu Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yang Shi , Mike Kravetz , David Hildenbrand , "Kirill A . Shutemov" , Hugh Dickins , Andrew Morton Subject: Re: [PATCH] mm: Wire up tail page poisoning over ->mappings Message-ID: References: <20230815210659.430010-1-peterx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: ffyfk5jz7bzrrjhie9h6jroinpsdb3qa X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C5E4210000E X-Rspam-User: X-HE-Tag: 1692584948-960673 X-HE-Meta: U2FsdGVkX1+I7IpW5D5Afdfm8MwoUKhWoderT5nfGZUdsOI1V+UUChaDJxcpeBiuBuvnIqZqm0HlOz8pxJbdNXKxnCSAw0uMvWzYgo1vhB5QJ8JEfUniXlPMM70sKDopSotMDOG9CWuOPv4kEWz3zJtymUy6eWIngWW0pCRRQ1bQZpYyI2w6Ld8CfZdQeKZC6tfm69dm3eIW+9DE8D7NfZ1D0xwnIOtTiy/AqCR7jp9+kUg7ekoIfvE1lpzKu83DL5qzeXU4AK2PGIFlveCOAsbq9WcuFYWne7cHtVaxiWHNZZz8G8gKvXLhqELPGUBk3hkjdWCgrq1r1C65798wZMXBDZoALX3W/xXZ4/1cBttc8jYnnlCyVtq/saZ9ryWqKv8SHimDgUfRau3L+p7lVxXTOoXapdltkEzIRp2LP1CgfOYkm/bDVKb4ocssvvM4oBGfXQ94bvk73DNbxS7maO0enpySKKZFB4cwOE4KdIkCFMaETHCWB6XsMR6F/CHOl/4O21YkwwEp3BhY3zPcI3/jycj99HyvpEMQycozGpDSuR1YGlgke5t+MW1aznzh9CZMPLfAoNfGHYMzzkvykb7mkVkXcjd/t8XsTKxLcghRDrqdGXl7iWs0y7D0VnQ1/edXaEFesLB6GJxqMXUQD1s0WmZpbu2/nvHBd5S1DACpzrRaI2Ezj39SPeHdAe59pYPwL01+LW2YBR/gZ/dJwpnyqvEoGWQqQwhEYbw8oPnHjhwJLhVF2BbVxuPicgZGf3U105xUFKYrhsmF/6D09bIlL2egl0w5jPdXQG9NEIEBoMPolh4ML6oOBVwgqJUCjMcUOWuPm66GTo+WFRCcmUrxvM/M/2bKmFTu5VRJ8RLy+0k6ZyQLrv1NELCoXREH1iEfF0J6obEAWeang3wiADf8010uq2+VMXmRj/HsktOP3k3FyN6nvVe4l2P3K5aw+KLOpnYQjvU/1nzI/Wq KMINLtvf 2vDMNfOeTiNDDQP7iZV/upNYCrXozLGz9YIN9iJPWPgt7KVk4uDK6V96rjfK4pjOPfxxpBFoI6umsKpW83nbnVUshsMJw5UWGVOiE0fp6nAZkuCCbhZYGr+8fBl+Le5oTNy8qZgz4weN/it8qoLnRhAqNhfU9SEN4olajA50NPjgF3BHabQQS6wZdKfKg2VB4gMqq+djLgu7WcBFKfdYUghd8nyAAbCib8OXLkOeh1weRdZTZrXdODG+HfbaFETXXQiay 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 Sun, Aug 20, 2023 at 09:13:55PM -0400, Peter Xu wrote: > > https://lore.kernel.org/linux-mm/ZNp7yUgUrIpILnXu@casper.infradead.org/ > > https://lore.kernel.org/linux-mm/ZNqFv0AwkfDKExiw@x1n/#t > > Firstly, I've answered and you didn't follow that up. I didn't see it. I get a lot of email ... > > > More importantly, I think this is over-parametrisation. If you start to > > > use extra fields in struct folio, just change the code in page_alloc.c > > > directly. > > Change the hard-coded "2"s in different functions? Can you kindly explain > why can't we just have a macro to help? Because it's unnecessary. You're putting in way too much effort here for something that might happen once. > Setting tail mapping for tail 1/2 is even wrong, which part of this patch > fixes: > > @@ -428,7 +428,8 @@ static inline void prep_compound_tail(struct page *head, int tail_idx) > { > struct page *p = head + tail_idx; > > - p->mapping = TAIL_MAPPING; > + if (tail_idx > TAIL_MAPPING_REUSED_MAX) > + p->mapping = TAIL_MAPPING; > set_compound_head(p, head); > set_page_private(p, 0); > } I didn't see this. This is wrong. tail->mapping is only reused for large rmappable pages. It's not reused for other compound pages. If you really insist on cleaning this up, the special casing of tail pages should move out of page_alloc entirely. folio_undo_large_rmappable() should restore TAIL_MAPPING for all tail pages that were modified by folio_prep_large_rmappable(). The other thing we should do is verify that the additional large-rmap fields have the correct values in folio_undo_large_rmappable(). But let's look back to why TAIL_MAPPING was introduced. Commit 1c290f642101e poisoned tail->mapping to catch users which forgot to call compound_head(). So we can actually remove TAIL_MAPPING entirely if we get rid of page->mapping. You probably think that's an unattainable goal; there are something like 340 occurrences of the string 'page->mapping' in the kernel right now (and there are probably instances of struct page named something other than 'page'), but a lot of those are actually in comments, which would be my fault for not fixing them during folio conversions. However, I have a small patch series which enables 'allnoconfig' to build after renaming page->mapping to page->_mapping. Aside from fs/ there are *very* few places which look at page->mapping [1]. I'll post that patch series tomorrow. I think with some serious work, we can land "remove page->mapping" (which would include removing TAIL_MAPPING) by the end of the year. And that work gets us closer to the goal of shrinking struct page. [1] device-dax, intel_th, mthca, cortina, fb_defio