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 8CCAAC27C52 for ; Wed, 5 Jun 2024 21:12:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CD9D6B009F; Wed, 5 Jun 2024 17:12:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 07CC36B00A0; Wed, 5 Jun 2024 17:12:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E5FA56B00A1; Wed, 5 Jun 2024 17:12:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C6BA66B009F for ; Wed, 5 Jun 2024 17:12:35 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4CBEF1410FD for ; Wed, 5 Jun 2024 21:12:35 +0000 (UTC) X-FDA: 82198083870.28.2885761 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id EEA53C0012 for ; Wed, 5 Jun 2024 21:12:30 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="h4WxDr/K"; dmarc=none; spf=none (imf28.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=1717621953; 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=tyPAwm3M+1wVMHk+k1F92p+/vIG4V+hj4p+c1Kn8nfU=; b=zMe+R6wm66WpBziTFs/XyoQNkvWAR64DUlv8ptkVJZWJ1eeDWEnPZH18a0ks+Ijd+3c+lM 3XXoR2KXL0VGVBtax2aI70fxR/etZLh/qBrLTeL+wOvJohgGKb54KNxHpmFsLWeVmJCd22 d0+/mW+3GyTZVkTivV8Vq4hgtlyQ4XM= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="h4WxDr/K"; dmarc=none; spf=none (imf28.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=1717621953; a=rsa-sha256; cv=none; b=zJzQCYrihEhPezFJHB5i3eSxyyWs/+YWWrdFCpPTYHKnLpGlo/SqrDFS2mE7kDU+GGTIG8 dsmMJjwz1O7uN4zbvn5GEH0/zoV4QuuNtARQhjnubgYPXDdBGElVP/syOEH9pwZ2QZI/0q MN5kdB0+1D4IJuSp+rwjJsjSMrXD6mw= 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=tyPAwm3M+1wVMHk+k1F92p+/vIG4V+hj4p+c1Kn8nfU=; b=h4WxDr/KHzPoTSlsJJsCtT+cv+ h79QXhcGqTuYAp01kJh9fTZKQIYEFL+I5cNQ9bRz1b3jtHibJw4SfnKXczxJ5ThUoyOesgKKiueA5 dgIwr/11mhmHDR0Ni44oELi+1c+IJPR176OT55zYhqKzyJa0+8ZQPdjcAB9RVV2pgYkcHSTb8TAen jjktNWOFeAELuaWLQZyZcdW/e1LAw7loshY2I+oxjdyuzm78flwaaTHZ0ah4OfJdPOqrmxvJuDiiu SZdFc8y4eAyIy21DtfM7uzbSMprsWC05e//u737zLhd9U/2g7Hp0XDGz3P76a7PhGPNKfO59N5ptd dHUWN33Q==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1sExvS-00000004CDq-38ak; Wed, 05 Jun 2024 21:12:11 +0000 Date: Wed, 5 Jun 2024 22:12:06 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Alex Shi , alexs@kernel.org, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, izik.eidus@ravellosystems.com, aarcange@redhat.com, chrisw@sous-sol.org, hughd@google.com Subject: Re: [PATCH 02/10] mm/ksm: skip subpages of compound pages Message-ID: References: <20240604042454.2012091-1-alexs@kernel.org> <20240604042454.2012091-3-alexs@kernel.org> <5bb3bbf6-6a22-449f-96f1-b9476357f284@gmail.com> <8a614d01-191e-45d1-b6b6-c36ec0bd9e5a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a614d01-191e-45d1-b6b6-c36ec0bd9e5a@redhat.com> X-Rspamd-Queue-Id: EEA53C0012 X-Stat-Signature: 44rdg7niccptpezxirci664a9xzgs93f X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1717621950-537641 X-HE-Meta: U2FsdGVkX18MY2yc7moV9ahEzYUORNdHlRAeqz1TyZ/Qja3Z9ROmjGF6cUQXEOsFBGfWYCIugoBeZrFVP9u0t+wxy+tU4T16c3bkc3f6JBw1ynPR+AFG0NSav++qkdlg6A0XaPBPfWeMnlkziH7Mx4sb9/5urbWRFfQdvVKmdS93vwhlnj7k8MyEsCzPYJQuOFCS0xOW/j/kNZvI3PPwmm1CYKpdbu6Wij5IfXXALxDtV8Qsx/X7grLOoHUVZa6anVLbuv8Se8O/gLdxzMLU6Tn0fBdF+Xrd6PRTawztghGlb3tkIajvk2rJGKR8eeeQq8mmmUZ1DYvtLVkryvecAA5nJhvGEEvj/kaTv5+MIQDYRoCBiVwkE4t0T/yavnY1dNM7m/fIKxV6NWaDSWEhp8tOnfAoCqWYKvkjEbgHvf0W494p9xCIOEXyFz/WfN/DlNZV0IpSTs6CfcaQjVY/i0NphR3c+EjPufwTYZG63cIuYh5kVZMoxoWOmoVelgx1Vk3PtQeuq4K4CCFQRk3w4hdrUakENeIXTd+/7pKJoMAwUDfIlMKV03aKfogIFnapH7G1RYnErNAQ6IOFE5jdK1uqlTgaIjjCiWOfnDN/HcL+iZCUoepOBi6IPldEntPIZLsjXbPDiA5wgsbKVMQu+tslh2yTpdfGkJGZNAQrTEEtd0VegvrqfzkH827LYqgaxe1P1TZo/DBWBGnPVLldydDhfBWGO0SNqkjDj6xLOyksd3+nYzM+BhgUhL5h+V/4VYgWiGTVaO+qer+GV3YkxeZjY0UAIGiINu5KZUwWvnB6HWdOFLyRW18cAIdT2ZawSjW7GRZ4nvnO6T7vZWMbDIsqW/11aImtf3fMOwqo7kHQSKsGVn3e9wYuk7y5vN5TtP8Dz4ha2PQaVU/k5mjAh8h+7adimPMALB0IpiPc5lyhXmo1crTMCZJwxOTBwX8xY9rfF3V75gfcYKaKLYe ZkJUqjcL nbV8lSFc1NQEjbLm0t6ZdP4kogEWeY8mOPNCPwBonIEwuMGxcBQ3f4zsFuLf8jj2stHvNak6pTefZlXzio08OPbw9sbp3fbuNWaxDc+aakNMy21edv8uwEQRMbsgPmqsR6tSHu87eF3sCZQzvaEmtljsIIcIvM+CKybMWdhQ8X7NjX/rF038GM14xcmikGlBbdTbm 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 Wed, Jun 05, 2024 at 09:47:10AM +0200, David Hildenbrand wrote: > On 05.06.24 08:14, Alex Shi wrote: > > > > > > On 6/5/24 11:52 AM, Matthew Wilcox wrote: > > > On Tue, Jun 04, 2024 at 12:24:44PM +0800, alexs@kernel.org wrote: > > > > From: "Alex Shi (tencent)" > > > > > > > > When a folio isn't fit for KSM, the subpages are unlikely to be good, > > > > So let's skip the rest page checking to save some actions. > > > > > > Why would you say that is true? We have plenty of evidence that > > > userspace allocators can allocate large folios, then use only the first > > > few bytes, leaving many tail pages full of zeroes. > > > > Um, that do need tail pages... > > Is there some way to use more folio in ksm? > > My take, and Willy can correct me if I am wrong: > > "struct page" is not going to away any time soon, but it might shrink at > some point. > > That is, we can use the "struct page" pointer to point at a page frame, and > use "struct folio" to lookup/manage the metadata. Right. > That is, use "struct page" when accessing the actual memory content > (checksum, testing for identical content), but use the folio part when > looking up metadata (folio_test_anon() etc). In the future we might want to > replace the "struct page" pointer by an index into the folio, but that > doesn't have to happen right now. My current thinking is that folio->pfn is how we know where the memory described by the folio is. Using an index would be memmap[folio->pfn + index] which isn't terribly expensive, but we may as well pass around the (folio, page) pair and save the reference to memmap. > For KSM, that would mean that you have a folio+page (late folio+index) pair > when possibly dealing with large folios, but you can use a folio without a > page when dealing with KSM folios, that are always small. Yes, agreed.