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 11065E77184 for ; Thu, 19 Dec 2024 16:52:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 993626B0088; Thu, 19 Dec 2024 11:52:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9434B6B008A; Thu, 19 Dec 2024 11:52:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 832186B00A3; Thu, 19 Dec 2024 11:52:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 65C346B0088 for ; Thu, 19 Dec 2024 11:52:08 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 195AC1217AC for ; Thu, 19 Dec 2024 16:52:08 +0000 (UTC) X-FDA: 82912299834.13.2FF0DD6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id 32E3714000E for ; Thu, 19 Dec 2024 16:51:43 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tJ+ZI58m; spf=none (imf23.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1734627095; a=rsa-sha256; cv=none; b=HWENocQlRV8tmb5j8KY3wsMjgLJDkhPzKv5tkZ8WlkJizHGF8c6dD2VzTzyrYG6HXD5s5g tciOx14epzhuV0sHdzzsrhGeMjzBNMnpXb2L4boKwM6xaFHrx/awKf8aw2K2YP0W4X93im MrJFsGrXtREZzsba32vNrlpx9iSQXEs= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tJ+ZI58m; spf=none (imf23.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=1734627095; 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=g9BcSRrxUykMMVWj5F8KcTDiGGo2F5oqCWeRlheeGGg=; b=aJtqvt+HRqw2KANsSaWPRj5CYBw/b/cXpbFWJm3GEQbgS/9Sw5dEx69I6l4Jl/Ytcbaldp XkGLd+FLJo2Yxm/qDP4WNr2KRipi8s8y0VD/AmcG31uXdb9OShLo7h4NqYEtkvhqOXULj4 P7LlmT/n4+Ilb516hW+/kGOVqhOPBpo= 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=g9BcSRrxUykMMVWj5F8KcTDiGGo2F5oqCWeRlheeGGg=; b=tJ+ZI58mvRmrTmN7x4Gn8NCaZU aZkT5poG1xFZfz25ezJSCIsiuAiAL1Oiy5jDhYklV1RpcN+ZjDnwrfyLyFEToD3QJps+kRl22GH8V Om4v5+zoa+kIeq04ExYu4O8dv86iRjTc2k+KD/5jD3ix2upX5pKe+LPEBMi9lDLSD+qqfIwnpv60U dTZJYUgyLEfIJbV8PbQyydSSmXg/Mo06GFQ9qzUgtNezXlxRvPrAHQ0ZIViqXLBv7LBbMZXaTVQzS 93X+rHw0bsnFOgWT240xbgJSnXd43Ns1Xvv9aFl2wVPNvuQvFLbzafJfZGlXYiZsvbOZAgau7NOU/ 7q50qrpQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tOJkq-00000004PtZ-2XWa; Thu, 19 Dec 2024 16:52:04 +0000 Date: Thu, 19 Dec 2024 16:52:04 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Claudio Imbrenda , linux-mm@kvack.org, linux-s390@vger.kernel.org Subject: Re: [PATCH 0/2] s390: Remove uses of page->index Message-ID: References: <20241219162252.1025317-1-willy@infradead.org> <9d4efc2e-56d9-4786-9ccb-ecd15f34f3e7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9d4efc2e-56d9-4786-9ccb-ecd15f34f3e7@redhat.com> X-Rspamd-Queue-Id: 32E3714000E X-Stat-Signature: ege5tn7qq6ptyues83pie4kwn4ad8oy1 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1734627103-135167 X-HE-Meta: U2FsdGVkX18y4LLSXp/LjlOWvUxM/vLXJa/HHoK0/6zN+ZceZc2YJN8aag1HgrxlygCb0/VoTDFrRZxq7mHc5R/Zwx8cZp4GbP+PX3hrNYSbC93B7G+h6cGD/kudYSbB3siSWNW/kdHW40RfFDK84M31Oo08TTuMsyrl6kS8D5Qq7TW+sJjAC60G/Q+fMkMfXazJsFyzZoL/mhxNNwPyGcMSRk2FpnOkIvtLI0Oh3MOqs2I7O5KD7/vvNnbDEOUqaz/wM7NNGo41d0UZWvbXnfQUACGYf7/f0Vucg2RcWkwTESLW5WhhAcm9sUhHMEc0QGhf3j1oOOCj5hhncIIxVgn73Fk9DrkdVLRZegIMBXzFbIT7nqBvQBQ8v8Ap6m4d6W6cnbudKZYt2zpyBPpK08/5SYT6fE5pBgHgMtM4V6xc77Zxc2vpDFD2e/gOzYOdhyXSo3Pfojduzt6XIkzGcWT2NyyciYhQdTz5+i4wdTnh/P6yJ4EoC4arHVXD2HruygVtmdLecSIlQaDz/NiXIXjz9o9Lp/Y1Wmtv2B/7lS606HP4UPfpPqNgauWfHX/PPO7SSoafYSEIYhm+F04LLCEOoLivC/+qra8HKko4goaN35eE0xu6DfhCcX6JlKINOVm7c036ndCkc3uBaYMxV2lpeE3cH1CSKwkvIY4S2oceTbWeh1amGw6J780sROhh4NPdcZuHT19WYITLu6P2fAdXIBjFH/ppGbHa+6tTL8ohTjc1p/uECaK1KTX21uaca2zUgt0dYlC6ZaJRkqDzEqldpxvrP9kDrlCn+cHV2M8kwQs5Ax85jwOJ7NktcBWsILIC2HPJLXdw4zJl+E8WXakLA1Trr4AaWEuv9dIvUfYNL7E23/bfipXGSD2kxz/19532byBfhF6m4SRZK6r4WV4PH14vcEQ41xdqnvBJeG5tADqZtSNqhjXf5vPbRoFXigWVb8ws3Hc9AzFaGrk v/fgf4oP +fUdDBGztNpzd521PwXqJkiq7H/50EnOKWFUmBZG1N84TltXnzWguQaBD/QmQt+L0Rb2nGw0UZJ2hwIvxeeZiWgLOgGuvijGf2kWHDt79QzUBtaXwUSlE3V8zUrBBrse6+pdLWPrBgozRo3QT9s9du9sZXYUvdjMbTcx/hD+F4FUyieL6QagnsdDMXL/B9TKmAsK6ghXkWrwDevpuWuDxbPxoiM+8KtVfLaXa 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: On Thu, Dec 19, 2024 at 05:33:32PM +0100, David Hildenbrand wrote: > On 19.12.24 17:22, Matthew Wilcox (Oracle) wrote: > > These two patches compile ... I can promise nothing more than that. > > > > David suggested to me that the gmap code really should be using ptdesc, > > and I think I agree with him. The vsie code looks quite different > > and probably shouldn't be using a ptdesc, but we can use page->private > > instead of page->index. It's not yet clear to me if we'll ever manage > > to get rid of page->private. > > Just curious, does that mean that memdesc would always contain these > additional 8 bytes? Eventually we'll have a choice to make. 1. Shrink struct page to 8 bytes, but we'll need to allocate a 32 byte memdesc for all the current users of page->private 2. Shrink struct page to 16 bytes I genuinely don't know which will be better for the whole system. If you're asking because we can defer some of the mapcount work by using the 8 bytes of page->private to store mapcount, then yes, let's do that.