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 E6195C54E67 for ; Wed, 27 Mar 2024 09:39:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6031F6B0095; Wed, 27 Mar 2024 05:39:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B4096B0096; Wed, 27 Mar 2024 05:39:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C9C76B0098; Wed, 27 Mar 2024 05:39:41 -0400 (EDT) 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 2E4036B0095 for ; Wed, 27 Mar 2024 05:39:41 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BAD10160C19 for ; Wed, 27 Mar 2024 09:39:40 +0000 (UTC) X-FDA: 81942321720.05.745EC99 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf10.hostedemail.com (Postfix) with ESMTP id B4C2BC001F for ; Wed, 27 Mar 2024 09:39:38 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711532379; 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=UB+yL5g91yZkCF5NRqA2Oe9zW8m5BIEfgBUbSLFF+lo=; b=VAwiSCgEd4OSc8pGGU3kqWPevLA1S90V+5d1WTVr+nVg65VNihuWmfy+tE91MNc7mSEMgP PJJwaiWQdUIdt1ODSBHC8Sk4KlQ1ZhNNHAD4eWLvR8CQ9Vwea+GMdkTKYeD9L2kOh+GgZK PizkdAWBlPAI6Bym2GSFLIfi1SoFqC4= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf10.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711532379; a=rsa-sha256; cv=none; b=JTupSbFPfmHDDgtv/uzmzs4afuiW8CQmqxvmwkY/eMQ/GfrjcoINzWHb+ZH6VjwJctMplf ZliEBo2apCXIQUBhBmFGhif07CysWCenwaqsI53OtUAUtDKrNWH3gUNERg82+ZmfVFJHfX fqJl8wcbQDOEuuQZzXw6uOjf44TQRbY= 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 A3B8E2F4; Wed, 27 Mar 2024 02:40:11 -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 0691C3F7C5; Wed, 27 Mar 2024 02:39:34 -0700 (PDT) Message-ID: <7ab73804-4f9b-44d3-b473-760a33460eae@arm.com> Date: Wed, 27 Mar 2024 09:39:33 +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: "Huang, Ying" Cc: Kairui Song , 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> <58e4f0c2-99d1-42b9-ab70-907cf35ac1a7@arm.com> <87a5mkm5wg.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Ryan Roberts In-Reply-To: <87a5mkm5wg.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: B4C2BC001F X-Stat-Signature: txkrsxtrcppwupraxh5yhs7g1he9h8nn X-Rspam-User: X-HE-Tag: 1711532378-612382 X-HE-Meta: U2FsdGVkX18F6yc+cnZ2UZEM5PN6MLsIFAdNCQqpl9xmc9eJHf2xogobq/76vTbNvxZc3Zj9pq92dXiRyp/VKVAhYkqMScV6wJQL8o2kbWXL/EoqfC4ezo8b29Or13nOBpCRWY1Af7pvycHUyrlZM7cLVgkqqVrNRxDNZssME27TuSCPcXZgPNbzpE7MH5AW2ITK3ZNrLeXTMyOg8PNWj6ZWab0YUwKzioG1JDdzJR18BTKSKarXpNOl5HMdHCf/5Hy1jcj45QWcX/tDVDJIo3y2kjH4cTfdk10RkKdYP2ksNlTPrblW6eqEH5v+wc80ru7nQ98yk3oX0NlhoQDh8GTP2j6cvuQA9alc0xq+LQx7b3GGQNEOgEdbE0mt+3NBaFbgAtbpbcJ3Zq8mf9XmsYaOgWvj7asZi8BbKuicjiblVsvCmE9rTWx0hlH5tsNpKPBMUlrgJms3pzDZTIwu0eXxxDHS+gdQmC7iS7MtetdGNMJ3oh0wXZnA4zslNHXJQdwh8tgIRcQKvWHM0mRyYTUsaw5TBSCejAIicHyI9DZa7PnFZTEzm67cD5br1/3njBPOdBaBcOlMXhit14MXrQ2TZA9Gf8rerynCzAFWGuiq/seeX1NJf88l0gNEiiPB5aKc5+p6gANKY5sF977PmwE0fE1Xfy6UAiLg8Bdo34dUZI0YYQB4oYqQiaoUyT9S/9Wt5gLgkQeucD3RnFfHZMkQV1lNIhNAmzWQ0JXWoaubc9of+yTj9iC7uw+Bc6lNgbD0m0bpxWbw8PtdaInWpPLtrIxdQITiy8L1qQTHLGPXK3sgcfKCsoK868JdCF6YC4gsC7GmTwmjcI7FkTlcSJEQ6gJ0iFvvCOF9ihBZzaO8kevg0fALXkdPj7/xgRVXdeUSxW5rH/Fis8j8XsgUmEoaR3mZ7i3URkJX7Otyiu4Z28WJbK+19POz0mAYHEu36rk2wCbfChEcuZlCAAk 7tEhQD3X QOEpAs3ZTU8vvL0pTrNXps2b/zz09HXVkA6xo2/A5ioRaz0u8ra9XmyCgf4BWgsHB49jUPxNrAdHaKytewui4VyUpfasn5xLN0EEFng8T5JlQlVqt4HRV+wgEyW2oEVTYd8j8Ob0L/9yaiUWFHTwXYwcEWAFDfoeP9H2RvhAgLvtamCBv2lpqgGZoMbsDE7CZknxvnt9LqsZMnCJX9xCtOFxZCZKY1YAt2deBCkpKMGguCHDvg4oURQQLjORhcQdmuPzlorqKJftDC3jvoY4sX6mJbNvFRxcn5EDABHd06f+xz4gA8tztCigcfqSrL6QlLwtxy1eqySwo/fI= 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 27/03/2024 08:32, Huang, Ying wrote: > Ryan Roberts writes: > >> [...] >> >>>>> 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? > > Perhaps, shadow is used to support workingset protection/detection on > the anonymous LRU list as in the following patchset (merged). > > https://lore.kernel.org/all/1595490560-15117-5-git-send-email-iamjoonsoo.kim@lge.com/T/#m962395eb5968c74b0c4c8e41d4b0dcdd3f28b2e6 Thanks! Although after reading the cover letter I still don't really understand the need for splitting. The LRU applies to whole folios. > > -- > Best Regards, > Huang, Ying