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 388D2EB64DC for ; Wed, 28 Jun 2023 18:51:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AAE2B8D0003; Wed, 28 Jun 2023 14:51:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A5E8F8D0001; Wed, 28 Jun 2023 14:51:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 926B88D0003; Wed, 28 Jun 2023 14:51:26 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8081C8D0001 for ; Wed, 28 Jun 2023 14:51:26 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 227361A0AA7 for ; Wed, 28 Jun 2023 18:51:26 +0000 (UTC) X-FDA: 80953049772.01.CC11130 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 8ECAAC0014 for ; Wed, 28 Jun 2023 18:51:23 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F0geF1mD; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687978284; a=rsa-sha256; cv=none; b=ODk+GlvkUh7+GZQ3MFfmPfTHk0imhqBHRQ2+N/MyvvfBE4NqYCtM1za9Kk704B26hSFW3D Z+zFtaowTIP82nTWAF7BihjKZs1hrcyvtBj9wuQxkHohbH9uZdy7xb/3pi8LKuipA+zlKN UlakC6Rmu5DR9O6qir21KerhteLmB4c= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=F0geF1mD; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687978284; 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=gzBVL7uWfH/0QncUeiWSVvNT7tu19KKFpZm/SdtHfy0=; b=PK/lyoiyxaXgltl8HvbfadGkEYnvbeCVMtk64GvXbpjBOiXcKeOdJRxaFssRc8k86c4eeM EdkaG1VoLpMUwH0B724fXIfFMkBBHkA+26aJ4/Xb/2Xkvn8aeyJHkUoIrBAanXO17+rYFG W/Kh+bdDomG/BhZBFbZm3IDEloM5IdQ= 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=gzBVL7uWfH/0QncUeiWSVvNT7tu19KKFpZm/SdtHfy0=; b=F0geF1mDFUhFwejscu79P5AerF ChPxlz8AungTNw2nYlH8TmeT0FdBYZ403uLo6dwYbFZivePasVeM2QOKhl+SGZUnj3aelPYXtEfM9 SrOHM/3oUTni3eU+S6cGIy3fXu368hUaiU/EA6YN2NOx+dDC0fkki3YX0I7X5QXDEfuDII33co6YT AgpMwEBC4ya/EPvRDl80CtdVgP3e2XagbMLqDsAoh6VP3gh2KZpEwz3m1/E0HTdSv3vSxKIUbldmu z9Fsmk0Dd2L6fefBSyj6JHJ0VqW7vTaNglMS0xkY6KNSksqhU+OkIfDiDfBXKznANmEoK/ikyWU4U 7raG+AtA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qEaFx-0047Cx-Rw; Wed, 28 Jun 2023 18:51:09 +0000 Date: Wed, 28 Jun 2023 19:51:09 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Hugh Dickins , "Vishal Moola (Oracle)" , Andrew Morton , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-openrisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, Catalin Marinas , Huacai Chen , Geert Uytterhoeven , Thomas Bogendoerfer , Dinh Nguyen , Jonas Bonn , Claudio Imbrenda , Paul Walmsley , "David S. Miller" , Richard Weinberger , Yoshinori Sato , Dave Hansen , Arnd Bergmann , Christophe Leroy Subject: Re: [PATCH v6 00/33] Split ptdesc from struct page Message-ID: References: <20230627031431.29653-1-vishal.moola@gmail.com> <90e643ca-de72-2f4c-f4fe-35e06e1a9277@google.com> <26282cb8-b6b0-f3a0-e82d-b4fec45c5f72@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26282cb8-b6b0-f3a0-e82d-b4fec45c5f72@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8ECAAC0014 X-Stat-Signature: w9motiwnmxj1epx8r1oxr1cy7ik3cbqg X-HE-Tag: 1687978283-680166 X-HE-Meta: U2FsdGVkX19m006S3UQ1R7Z5o2vI0gNxlVN/0WTpHof10xyC3v9J+yRMaQABxCcte7DFwBVqp8Uxf4pmPJaxlXdDAEJOe7JIbHmotfZCMCwpEMQBSrRMyZw6tO1OuA8CTTmgYjgkClM1e8WnRV/ev5omFuWbVEJUfeDj/+TdAcd8YRIeuNLVv32r508Q/5n7jthwNcJycmk8iTpqGxcT7rbeJNc/3HlWmC0nxYTcQ+/k18U9P5KtbnwACerA6NGd9/1LPs03cMtjNWKB7ypDoAiLDbrY16XwNDEgif/wUEn7o7Z93kxQk15gJIJuACOBvnj8EGnaEDsUoD7n596cJ7ptA8XFndlQtYvfaXdJ4IcxCykGaD6jZFhr6wJlS0JSMjaGsPza3czIXv8L094HN5uTQEKt/NrrF2mSukQTyzXmQId1ZZg4ptJMxoTGSh3QD4Y4xnhqA7Osqb+KPtUl+KJJk5cryqDCI8eTFon/64d/svNBQVUAFdIf/GZEuFMjPROlAmdbcS/0MHh9SGHQdgb7LPXU+Ok6eypqk0nIoeUEbNQo3kbQ/DP5/d7GvA+SG/1KGqZUBseU5dRx47v3hzVFcQeqymFQ1peK7bCCgCLcWgnLk7JBlwWfYDnS69YQkoafnDNyTSX4vor3zu8wHKT8YoaODWHtijb2xnwE6QcJydzSnOmpj6pz8yravm/fYhabXD003q4PWS2HYgHAXP3MtMPc722YTDuFCjmffbl928PVSFYmqC3Y6cpKVswqxoRFC9WVvSJ/7wPiPHUtJPxhR7ntl6L1O5T3z+6p96C5xyFlHtJHsLH4dPSqjrV9WqBmlrbDfuOlF8QpM1mKtqvDpPEKLR/WLQPx5p9P8mveij1HGWEHS+licdGEkQ3MVY1ZOeO3YPKWD91iqYbTJA8gbQ4AXJ1/dCYsJdonGnQ2Nd9hs/T4VHYtakq4CEayqiw+dnSIlLUl0e+0tZ3 9Pdum8RN AGZBE22jwZabSIheMO7HSmcarT+P8+bM2e0Jm9da5E0Z+lYcBKh+Qc6zwAV61f4ipl4yqgY+gOrOje7NcjSS7SgLlj3JcXbkaeiQC5K025f5J/LxBZDrHnmbdxqNFHBM0mJge2sraCv3PBeKAoYFgfMUyyilcgqRt6aVINKyvRA5k6ezvxrsH4n48cMloJfMFwmLg8iPhLi+T0eByDB8hExK+xQ== 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 Wed, Jun 28, 2023 at 09:41:18AM +0200, David Hildenbrand wrote: > I'm not a friend of these "overlays"; it all only really makes sense to me > once we actually allocate the descriptors dynamically. Maybe some of the > existing/ongoing conversions were different (that's why I was asking for the > difference, as you said the "struct slab" thing was well received). > > If they are primarily only unnecessary churn for now (and unclear when/how > it will become useful), I share your opinion. One of the reasons for doing these conversions "early" is that it helps people who work on this code know what fields they can actually use in their memory descriptor. We have a _lot_ of historical baggage with people just using random bits in struct page for their own purposes without necessarily considering the effects on the rest of the system. By creating specific types for each user of struct page, we can see what's actually going on. Before the ptdesc conversion started, I could not have told you which bits in struct page were used by the s390 code. I knew they were playing some fun games with the refcount (it's even documented in the s390 code!) but I didn't know they were using ... whetever it is; page->private to point to the kvm private data? So maybe it is harder for MM developers right now to see what fields in memdesc A overlap with which fields in memdesc B. That _ought_ not to be a concern! We document which fields are available in each memdesc, and have various assertions to trip when people make things not line up any more. There can still be problems, of course; we haven't set the assertions quite tightly enough in some cases. People are going to keep adding crap to struct page, and they're going to keep misusing the crap that's in struct page. That has to stop.