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 16B12C54E67 for ; Wed, 27 Mar 2024 08:27:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3C036B009E; Wed, 27 Mar 2024 04:27:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EC346B009F; Wed, 27 Mar 2024 04:27:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 88DDF6B00A0; Wed, 27 Mar 2024 04:27:42 -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 7568B6B009E for ; Wed, 27 Mar 2024 04:27:42 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 45B2440B38 for ; Wed, 27 Mar 2024 08:27:42 +0000 (UTC) X-FDA: 81942140364.04.289BC1E Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf16.hostedemail.com (Postfix) with ESMTP id 2383F18000C for ; Wed, 27 Mar 2024 08:27:39 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711528060; a=rsa-sha256; cv=none; b=dSe8IPTMTm2yyJNbGi78CT9IykeFNp7Sf2dDX7P1mNNm2gfLsm1+XAY8VT5hlwom10ZM3h fu2HUT6D7iYTcWHAkzd4wLrOOX/htHcmn1oOWs6J9qH++sADW+JEKiZgc+njF1nyP7ImwN f2jzHbkq+v9xD2W6tHPGUWyic2m4A5A= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; spf=pass (imf16.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711528060; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RC9w5LPQ61SNTK0StNOnm30ZrdLpqGFFFBsKI9hog14=; b=EZk/O9o6ROw68/d4+sNx13rJwLQljSH7eOvF0tGQkpbWljVDjou018iqNzDbdDpD2Fu9qW qxW2ahbjXTdN9/2JVxvyC+8gNW2UQRb4BRHdvhy4qNZqCCM/BcK/xz6z4FaNeIQkWzGzi+ SrPpcYLcjLsS7UaaISOM2Q3oqxlNNl8= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0EA8F2F4; Wed, 27 Mar 2024 01:28:13 -0700 (PDT) Received: from [10.57.72.121] (unknown [10.57.72.121]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 07C4F3F7C5; Wed, 27 Mar 2024 01:27:35 -0700 (PDT) Message-ID: <58e4f0c2-99d1-42b9-ab70-907cf35ac1a7@arm.com> Date: Wed, 27 Mar 2024 08:27:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 00/10] mm/swap: always use swap cache for synchronization Content-Language: en-GB To: Kairui Song , "Huang, Ying" Cc: linux-mm@kvack.org, Chris Li , Minchan Kim , Barry Song , Yu Zhao , SeongJae Park , David Hildenbrand , Yosry Ahmed , Johannes Weiner , Matthew Wilcox , Nhat Pham , Chengming Zhou , Andrew Morton , linux-kernel@vger.kernel.org References: <20240326185032.72159-1-ryncsn@gmail.com> <878r24o07p.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2383F18000C X-Stat-Signature: 7mj8gwb44cfrnwycq81f3suhtthip7hy X-HE-Tag: 1711528059-949697 X-HE-Meta: U2FsdGVkX1/nL8lPDjIC3EYpb8rdJ44K4PO2hNh5G49U/R7EXaM+5jXCKlvzNt5ZWD5XSQ7w+hOPg6cHb6hMm2HQ5bXo5RrR9wzvh0pqAa4aC19Wo/jqmf/BFQgZmQL+OIW/xRfQr+24t4cmjgumFuuJ08FcJzallQatWNjTTetv1t4w13nQSZ2L/QD7SxLdlW6lJUwIIjJcdjUBlyY7zex6JGEcGCRqNPUDEVm+4kTZmUpqrVbHV1f8RAZQlTBWvUAaKO1Et+aTTeX0qr02SMpFJ3/qCSPX8M2ksa0MgoRJ7W+SsgQyllJKnxsAvxkYcut0tpolCLuAOiPzishjYODKsYpREiRcO+Ne7VXqpq9CY4CtGpf6ZYYtUDMZf0Etkr+NBLarlKPAgmnVN+gDSnJnTN7IRpZc9IKTWtApjZX6cphaDCrhcfBUq/dmb5UpQ4EjFDZHzUHwy3xTxczUL1CNU8QSyczwp4lmJfjvOKhgA8NQr1h0TaN3EZAkMYDno8htu1MN57NzWc3YgCORRyTjbpBgRW2+RS5AFYQ0aHFnxvFm6hL+3R0bMv1vazVO7HnmOdPQomz/sVedBj5yXnt5oafHh+nHVW0kAbWI+H7SD9X4daJfLldbfGX7X+rQrlIR2GXOXr2GVYU6fgWrrwMVrzp8nVt1PUBjMpVd4K+MSexWdZ5mjKXFNu8nqsY+FPXmlb5EH7aDErBi8NP9D9IH+mQnQya0ODgh7BubCAXDqBYnqp/Ujxc3fEljUWDmH0rPFG6SoYp96/eu+wUQ4l9op9peDj3stccyWmb6099PxzvV1K2adxFwOPP7/zNK2g/Ic3JkcxmzHBmwRsR/KGMNvRzuqsy0N8eQV4sil6xkoWIVv+Bnu3iRf53pI0pTKgYX1p3uBLvt2zBy6bKE5HOTXztiAvv1Y54BszvhPNMGrw+mercP29/BJu2KK7OfRXEjoUJ89j0mCfvXPaR ZI1nC3Op gvwgQvPbF2mZfAUoG10EviIsGxV3ojiYN9GYqNfvV3ah2wdvjldY2AqTtxRRp/xKU5XFTo+l2ge1eO/ge/DYceiSFzZm9K8s0bIsCAPmA30Lso8GXXn4z0g0gwLb9Tl8AmwCrvInWyosnSo8+PbJcBX/w6A== 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: [...] >>> Test 1, sequential swapin/out of 30G zero page on ZRAM: >>> >>> Before (us) After (us) >>> Swapout: 33619409 33886008 >>> Swapin: 32393771 32465441 (- 0.2%) >>> Swapout (THP): 7817909 6899938 (+11.8%) >>> Swapin (THP) : 32452387 33193479 (- 2.2%) >> >> If my understanding were correct, we don't have swapin (THP) support, >> yet. Right? > > Yes, this series doesn't change how swapin/swapout works with THP in > general, but now THP swapout will leave shadows with large order, so > it needs to be splitted upon swapin, that will slow down later swapin > by a little bit but I think that's worth it. > > If we can do THP swapin in the future, this split on swapin can be > saved to make the performance even better. I'm confused by this (clearly my understanding of how this works is incorrect). Perhaps you can help me understand: When you talk about "shadows" I assume you are referring to the swap cache? It was my understanding that swapping out a THP would always leave the large folio in the swap cache, so this is nothing new? And on swap-in, if the target page is in the swap cache, even if part of a large folio, why does it need to be split? I assumed the single page would just be mapped? (and if all the other pages subsequently fault, then you end up with a fully mapped large folio back in the process)? Perhaps I'm misunderstanding what "shadows" are?