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 023A3EB64DA for ; Fri, 16 Jun 2023 20:38:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8ADF48E0003; Fri, 16 Jun 2023 16:38:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8385F8E0001; Fri, 16 Jun 2023 16:38:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 727538E0003; Fri, 16 Jun 2023 16:38:33 -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 648818E0001 for ; Fri, 16 Jun 2023 16:38:33 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 333711A0DA9 for ; Fri, 16 Jun 2023 20:38:33 +0000 (UTC) X-FDA: 80909774106.18.D88089B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id E60D240006 for ; Fri, 16 Jun 2023 20:38:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QBNdm8qv; dmarc=none; spf=none (imf12.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=1686947911; 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=fw74FAZhkocnJnJyLR/WQNNOz26kiObyhL++hGG0nWw=; b=8VtD4xrzVKwSXvNFUZTBDr6AWuj0KzPF2pXnNoUAP8eEWGZY9ClhCF8Wh340gU31WvxIe6 vFQXDnaw558zxsANYQLTCcnvddT576mV5Nfa17mc6VC0+hSJDW2skg6/kOoCxzSyq91uuS Cw9rP1rczvhsDYl1VU+7hy3gRlXrtq0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=QBNdm8qv; dmarc=none; spf=none (imf12.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=1686947911; a=rsa-sha256; cv=none; b=tkRFGTXb8Yqgg8XFj8Fg+c6Lf7MsktrrvSTqgcOQxNTY4cmqdybnTSN+yweSPKMleoPknY 39ufJjIFafqOIhdJASos4+MtvzmZFGlePWpH9Gs3Z1LmL9IY+2BnlTvFwfhYavYwlyPdVk lHVM3hmsZaUbecBu4LaIDQGuXODzmwA= 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=fw74FAZhkocnJnJyLR/WQNNOz26kiObyhL++hGG0nWw=; b=QBNdm8qv6j/A/iWrMKfpB6M7G8 dX02GHdjAg9rPGckqaKAq0nuLHgnEOZOUcT5iS1KFKrWFBJlTrkF2I4g5N2YgCfsexrQECwyFoHPp z6yd+/vIl/PequagU7pGV8UNE2yhdOrdkDT+t3SJSVONZj6Q1cQWhoxiK+7FUVh/Fb17OdOH8kjtt OWIuj2P4ze5K/i70TfCVLOSJSXO+Ry9WEoIoy6BlMNh0EJ1wlu/c8zXDIuEPPIicVlz2AV+6m8LDv lA4vOEDBJYuPKGoF8lu2OSuuFhx10iSF/LiB0UcYpqrALuMFJM02PbH03w+/bd9OLb/nrxdqasmpe J/m6D//w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qAGD7-009Lj7-EI; Fri, 16 Jun 2023 20:38:21 +0000 Date: Fri, 16 Jun 2023 21:38:21 +0100 From: Matthew Wilcox To: Hugh Dickins Cc: "Vishal Moola (Oracle)" , Andrew Morton , Gerald Schaefer , Vasily Gorbik , Jason Gunthorpe , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda , Alexander Gordeev , 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 Subject: Re: [PATCH v4 04/34] pgtable: Create struct ptdesc Message-ID: References: <20230612210423.18611-1-vishal.moola@gmail.com> <20230612210423.18611-5-vishal.moola@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E60D240006 X-Stat-Signature: om3nqy4rdtbcwjeq3k1f8mng8n3znxp4 X-Rspam-User: X-HE-Tag: 1686947910-562784 X-HE-Meta: U2FsdGVkX19vDsf4busJ0F6v0GFRHRFkdHdQ7PCTY8EYi29EcRnjVE8cJay+rHl8B8P+AlOBgx043Nn4wEYQf8xfo/5X5uq24XU9eMvG5i8NmtlYeA/Bz8CsIT0QPv6e1T+uT6H8FV5bqvebV2oYyfDaheg7EGi7O3b06LEK5vBysGzDd4jlrsAfj7bzncD7VomxT86Fl2fH4BeXrCgq1wgtRFcgm44/H/rlLWgrzpnvSer2MWRXZBx0BfeYecuSZ6ovBzNNJubgI6A4ufTzDjGOjFKYI/wQThOVL+U55LNF9Jsu3BuxRpqQGEsFFJoge+9ErGl9EjUKPQD5eGbGHelPSDEV5W6PvB2TRsyoI/IBU5crA/gyQ1I1fsygGDJxYsy/b3t/n752Ftnd1IBWJ7MccnYegWb895uPAYdE4Sucs1xd5O1l73VSCNMxvkhl5Br0WYSGQUUZFdKnolJkqPjZuDU2dP2Y0jFdQLURI8SJO0RsBx/aip2znkb3ASpd9D9+Lhw8NEjPhcVJtaHmXJSHLnm0tgj2mZt4GW7kyMQOL0j17vLUQ0hzDdEw2S8B1Zjnxz/o5SJXSb0acNoElyuwempWJ+0nB+TVUKO9OXXr4/RB55pNw5HVuSKLIZlxRfEnYFojchfzbsNyk7usEtrsAi4+hEe8j0nNcrDD5Nnt88hp/pTexCofAJFjnkGVRoSIX0hpqFtts1qVz0hxoUtXXZQfhFeFof54e3cVW+ENyLDodTK9XKJpqYrky5l0T0RcnUi4F1/MBJEEzsRJfsqq9LGcF+4UEYOwQeowoD5XOZwcvJxqFf6Uy3p1ZPeBwj0d21DwPcbjSs6lbbvPk0xx1GbCpjBImLaT5/JNp8PeiAcfVhDnQtO457TvauV8qhvEsfRthHt29Io7wGiQzDz0XSIyZC+k+epyqvtujMcYhZaNON7pXRVThGTfjYiPzwbumrlv2UZkQhvBcyl TmgyH5Y+ RmAD2aoE5iehJ42uSXIOnUUqbh28jvu6ofrSSfJRKp6qlwL9abNripbZjhWfeHuxxJnbBuzYFsRHxxNPrfc2bWXPgEJNIBsykboS7OcceGKQnJHKKwGTy/dKWV7n76EyX74StAjLH2KPStb9iQJO7R2qIuOb06DJxtKFO874BP3jysYcDDekyys3+Enk+1AfNHEt1xn5hPLQ3Pz5Yw5dPNz0ucA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.004883, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jun 15, 2023 at 12:57:19AM -0700, Hugh Dickins wrote: > Probably just trivial collisions in most architectures, which either > of us can easily adjust to the other; powerpc likely to be more awkward, > but fairly easily resolved; s390 quite a problem. > > I've so far been unable to post a v2 of my series (and powerpc and s390 > were stupidly wrong in the v1), because a good s390 patch is not yet > decided - Gerald Schaefer and I are currently working on that, on the > s390 list (I took off most Ccs until we are settled and I can post v2). > > As you have no doubt found yourself, s390 has sophisticated handling of > free half-pages already, and I need to add rcu_head usage in there too: > it's tricky to squeeze it all in, and ptdesc does not appear to help us > in any way (though mostly it's just changing some field names, okay). > > If ptdesc were actually allowing a flexible structure which architectures > could add into, that would (in some future) be nice; but of course at > present it's still fitting it all into one struct page, and mandating > new restrictions which just make an architecture's job harder. The intent is to get ptdescs to be dynamically allocated at some point in the ~2-3 years out future when we have finished the folio project ... which is not a terribly helpful thing for me to say. I have three suggestions, probably all dreadful: 1. s390 could change its behaviour to always allocate page tables in pairs. That is, it fills in two pmd_t entries any time it takes a fault in either of them. 2. We could allocate two or four pages at a time for s390 to allocate 2kB pages from. That gives us a lot more space to store RCU heads. 3. We could use s390 as a guinea-pig for dynamic ptdesc allocation. Every time we allocate a struct page, we have a slab cache for an s390-special definition of struct ptdesc, we allocate a ptdesc and store a pointer to that in compound_head. We could sweeten #3 by doing that not just for s390 but also for every configuration which has ALLOC_SPLIT_PTLOCKS today. That would get rid of the ambiguity between "is ptl a pointer or a lock". > But I've no desire to undo powerpc's use of pt_frag_refcount: > just warning that we may want to undo any use of it in s390. I would dearly love ppc & s390 to use the _same_ scheme to solve the same problem.