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 193FEC25B75 for ; Fri, 31 May 2024 16:51:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A88586B00BB; Fri, 31 May 2024 12:51:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A69996B00BC; Fri, 31 May 2024 12:51:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 94E266B00BD; Fri, 31 May 2024 12:51: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 763426B00BB for ; Fri, 31 May 2024 12:51:33 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 294F1812FE for ; Fri, 31 May 2024 16:51:33 +0000 (UTC) X-FDA: 82179282066.04.8EB7F78 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 40CB1140013 for ; Fri, 31 May 2024 16:51:31 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LrpEwZfW; spf=pass (imf26.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717174291; 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:dkim-signature; bh=UkriLrIuhlGHi9LhIpd4ZWl/G0l6/MfQ7MLNmuYsq5A=; b=aaT0M/ZDzq/5Wnu0WjelI1yKDCM10owSEI4mc1lt+u8m+VYKdOWbdybU6QhdoeyDoPRAOf mSE50U8JXwsoDZ5o4M8PP+9zUK2/L8e8KsnZ6fbYUHJlgoYqJ8jQngq7PZyIEDkSBkASZC +vQP8+dsyHcI+5V5pJe1XfQGVPASEO0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717174291; a=rsa-sha256; cv=none; b=TuXCIjUub8mqxURJCxpNFt8YwDFl21ZvVMBzXf9x7LXKisw+g8ZN7zsy/ZItG2vVS7ypVS tzzlgIeVjxfsLqbjl6Gg+q7DhmQHOMPFaq2SjKGl/KSnKk3nH/4BhLfxLBLNk5CPf0cxBP jDbxyGffEJe6aMlvnpL4FIOANfgA3q4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=LrpEwZfW; spf=pass (imf26.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 78A4162CF7 for ; Fri, 31 May 2024 16:51:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E916C4AF09 for ; Fri, 31 May 2024 16:51:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717174290; bh=kZTPAbxlO6PKzpx7rehZDv6JP8Wc5+Bkrzsfswmsza8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=LrpEwZfWKWSvwQXofLOlJcQleWpw+ZWOvTc/GdhH+1rpGNgPNHDkBFt8fzLq1VQAA OSdTXLnO1LkMma2bFLX5fJqQlyo6/t2c4OB3d5ayEFP+nxnDUpeSnwG+TzcQCezSW3 /rCAtHYtNuuZmlG7eIzpanxNXGDiduCWF8ybMi7JA3UmNWSo4DfinmRF4DZDWKq6mz K6tr985h5Nz2jzrjmRRfgUpQe3qFsOapxlcdeJM2s6NArKCKNxTcTLk93HVAr6hJfP puFrkGmEhYz/X6F1NZQipLq7JwT5SO/5i56oGa9HsBdg4lZaJDmsJoBCSvrWqmAqbh H2tigmGlCnPHw== Received: by mail-lf1-f52.google.com with SMTP id 2adb3069b0e04-52b8f5d811aso18422e87.3 for ; Fri, 31 May 2024 09:51:30 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWZ520OH9rFOd63Gig479Vms6K8CzDH1ixw+H6UAnuTptFZUdgWC7oXgmVwZVWtS07Q9tPD3OMpGVAGToC4oKUhsUA= X-Gm-Message-State: AOJu0YxJsaiNJ2zQ0Yb4Trm9fr6br7vJkpRu2/iYlh2LecxbwepuF4yl rJVo6c//8P1FtumjYsE3JHDJ4VDBEbbpY5KNeNq9Llrs7xuZx/8p1LNzKmeXKM6DCHBZgCDyNd/ 8+O9yZZ5yQ1bENyQm8gFIijlj1w== X-Google-Smtp-Source: AGHT+IF8IjK8isploGSOpU/9MYSS/w4GPu/4RkKZ+4GK71pFyNQ9GLJE95uGt35T5m9OTk1KJJ/6oPkFjRfTrtAYqCs= X-Received: by 2002:a05:6512:3e24:b0:52b:874a:7df with SMTP id 2adb3069b0e04-52b8955c5bfmr1952854e87.12.1717174288882; Fri, 31 May 2024 09:51:28 -0700 (PDT) MIME-Version: 1.0 References: <039190fb-81da-c9b3-3f33-70069cdb27b0@oppo.com> <20240307140344.4wlumk6zxustylh6@quack3> In-Reply-To: From: Chris Li Date: Fri, 31 May 2024 09:51:15 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony" To: Yuanchu Xie Cc: Matthew Wilcox , Karim Manaouil , Jan Kara , Chuanhua Han , linux-mm , lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com, 21cnbao@gmail.com, david@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 40CB1140013 X-Rspam-User: X-Stat-Signature: j34j3fbdbo5powxypokj5t55ugipukcn X-HE-Tag: 1717174291-642408 X-HE-Meta: U2FsdGVkX19eX/clNwTwFzW+t7WnJ0vtdCdaxHHNtmKfPfQSYM3sW4cfw4bg/x/+A+6WAI6+GPAV0F+7XvnBiNaG5oBpSpwJokEbFcrArR4MLbZ/AaE2pYCJ+5cDRQH9R9Uw7FkaCcCv7kmueWqZdHFYABKGuid42TWZtaWsTUuJ3d3UpAmi21NKTW5o7IPqAD4VaVRx1g6dtY4EC1+CGKl3HiXYu/zzrcq322PC16O0VO7V9MV4naX8qan+oyGqaK3QoPBZohIDJQTqchNWqnxVeQmtPY9o7CrVn5jVneiGg437+UUEVpvPMUPMP3fwDWmO20dvCh0l7rRQ1KBCwU/ttDDGhOovpmSrlivQm9ZOJuST9JR92EVRW5Sbu0wswkQm2VsuPHL6wOuX1Uw/1/omTnxQuHE/w++XGY8ruejGoyosQ3hP7tHFTQJEx/FIImu+QOhQ+xKd7O1w+V9YS4eE6nSU+KMTEYv3W2hGp2s8lY8Q+Szn78+ZItjrXwQWl4tnrU9xfKwRjAdM8Tk0nj3GyuUeRzz9Gm7g+QAs5GPADmhKOGbHTQ4RkM7GCfe1eOg8XR5NBhH7oHW9uIV1nLcK2wju453rx0tR/pgobmMPjCWWLsiRp7X5+YuN2AawffBwdfv23Qq85CAqSsEkRL9mC6blKqHqPfldJ8gOvdxUCNULmkPwLOgJNJNm+ZNg4grLNgLjsZfPdDQPdMG21/fYPj6cOQj81ziGmk4F5CqxWIfFUsLfq5uNYqoQ3eszoraeBPjag+HqwtG7A4i1oxq3i/01YDD7nMh2iHkDDf1EQxA1nqSolvoDArKbiDEZUAdYKe45aZ7gq6zIsgbQjPT2UNefd0McM1nJME4SryqNpXhW+m9n9xAePE2tHKH8tSyxo8/herSiXw/gmS8hAMpMcSmeLWAO1FvINr6zSmEisI7DiTiXmOns6bsdmJR+cnQ9MnhQS33iidNlk9A m4yqUUvk YqSeAwq4MXF7xe+1Vh2k35L70fZxxkTGU+tOheYdABnsiDOFivPB9/8vKlUJWpalQK5t17+L33E38ZXKoyxd8SIy2FXcNP16M6N9EeKn6wmOJZe2JpIgYpsy97i6Hl4HbxblapXNIPKCKny+d126sFQo/w/7EV+ZeXNHk9w1XF0ef5kEUAyOxjjoxyj30x1M56fXOrVoD2P6ORSGjyi1cghO111/rXoO4tPfrF0EinXtdU5o3d30Z8Iwr0huvRQBNo1ikg7gwQ3hWHfvl5e4C3GzTSztuJoVtqUlXmTQ5shCqOxap6ainohn3DTuEasOgUjcMVg6ub3OUvBki7uZYw4Xa51945/iBYvOvSbdjAIaetKxp2JUm/JbbhbIK0voW+Tulvgk3l/hgAcjjSo0/YHq7fbWjIubpbib2gCrh6gm6ur2tcfjz3YTB1Q== 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, May 30, 2024 at 6:56=E2=80=AFPM Yuanchu Xie wr= ote: > > On Wed, May 29, 2024 at 5:33=E2=80=AFAM Matthew Wilcox wrote: > ... > > > > Indeed, if we're open to radical ideas, the LRU sucks. A physical = scan > > > > is 40x faster: > > > > https://lore.kernel.org/linux-mm/ZTc7SHQ4RbPkD3eZ@casper.infradead.= org/ > > > > > > That simulation assumes the page struct has access to information alr= eady. > > > On the physical CPU level, the access bit is from the PTE. If you sca= n > > > from physical page order, you need to use rmap to find the PTE to > > > check the access bit. It is not a simple pfn page order walk. You nee= d > > > to scan the PTE first then move the access information into page > > > struct. > > > > We already maintain the dirty bit on the folio when we take a write-fau= lt > > for file memory. If we do that for anon memory as well, we don't need > > to do an rmap walk at scan time. > > > The access bit in the PTE is set by the CPU, and in terms of moving > the accessed bit into the folio, I think that's already done by MGLRU > scanning of PTEs, but the gen number written to the folios is > per-lruvec. That is the point I was trying to make. To get the latest hot and cold information, it needs to scan the PTE access bits. The walk on page struct in pfn order does not able to achieve the same thing. > I can't come up with a scheme > Perhaps the idea is to scan through all the folios on a system, > instead of evicting folios from each LRU list? > > As for whether anon folios should behave more similar to file, I think > this is an excellent opportunity to reconcile some special handling of > anon vs file. Because to me a swap-backed folio writeback mechanism > sounds a lot like what "proactive reclaim on anon pages" achieves: not > having to wait to reclaim memory.