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 8FA82C25B74 for ; Fri, 31 May 2024 01:56:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F29326B0093; Thu, 30 May 2024 21:56:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EDA0E6B0095; Thu, 30 May 2024 21:56:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC80F6B0099; Thu, 30 May 2024 21:56:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BEAB96B0093 for ; Thu, 30 May 2024 21:56:18 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 69ED68102C for ; Fri, 31 May 2024 01:56:18 +0000 (UTC) X-FDA: 82177026036.02.E010379 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf13.hostedemail.com (Postfix) with ESMTP id 9D4CC20003 for ; Fri, 31 May 2024 01:56:16 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=otybdI2F; spf=pass (imf13.hostedemail.com: domain of yuanchu@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=yuanchu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717120576; 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=K8460kiex1dGyxH6Zo8MnOJerHiw8ga2LQFjlzcqk8I=; b=UbR08y7dzV/yh8ZTL31sZ5RaN2WaTFxIxN6zTwENJ1m4ICHOwhzVLMbXCJOa75ZP6eYJDQ f3L0nn3OX+OCRyBKN35N5X6q6QwBJ3kR7QTnt7j3d++RmiZD78nLdw5RUiy7Ap7aDUfSbm EhQhqU+uCxGyMQ/mbFDEPIs46mundXY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717120576; a=rsa-sha256; cv=none; b=4pmtT4IeZnLVNuAgn9qEW2L1sKllu8uknlNLcXy/IEn9ZmZStzsX9OY4oFpg7g3hSW2ufH sllWWqPG8onRMsHJ7tDTHKCarUGajZF9rQ5fg90hDGHqKbD6soHNwE8PE1/PWdTc1Ap9pY 2gZ9QfI8mpn5ZL1WhBm4zKN0zi5+5pQ= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=otybdI2F; spf=pass (imf13.hostedemail.com: domain of yuanchu@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=yuanchu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dfa588f7283so1600399276.2 for ; Thu, 30 May 2024 18:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717120575; x=1717725375; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=K8460kiex1dGyxH6Zo8MnOJerHiw8ga2LQFjlzcqk8I=; b=otybdI2FnXwXX3ngylI5r3iQ5XT3dQPb5+py1xXMbUBtfZCNBjBrzVL72Z34nG8GF5 MyrmoWjGv/CvtFDyrXxb+FQOJ56bKov40fabciztnHHSjsxnKysGE9gBHMsUM7Wfx8O3 /yaH59v++L5uBKHgrKeen0ZP3DdJCTbhp5OI+H5IZIX0tXsUhzi0BfeHzBSxQGVWZWUO gmoOm+L80Tajo97DTRRF3/GjWsziG6hdz9fPBwtkrd8V/VRBwRh80Jw3DufZfLrrQK6H hKclT0rpXlRzdO/x5NL0s+jpk++SKlC6QN6chkmpJIQ2unlJ8HmdAg9zs1pJAwAlR+7Q qQmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717120575; x=1717725375; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K8460kiex1dGyxH6Zo8MnOJerHiw8ga2LQFjlzcqk8I=; b=NeSwSVcSAoik5++IDBCbu0D+d5KfF8Xwb+N/B+Dwa7iRHIJLX8eXP4We6NIlPAWsEl eZkNSV0psZyXV3hkldTvbDMVxxXan1aNIPoid9QVy/Q0s1RH4nQcjtPH3uTnq9v7Htvr qGXgTIjX0nZHClR26XNzsFg6UMKumSOz4Ne0DcEw65jx82WRy22O5IWXC+MQHA6mJRFv JP50wZwlTTh+kWFT6k3r5/G32D423Egmn+cucqu3yDoCfwt7f+PdID2bO/cg58GtZ2GP Jf5EPBqrNhP5Nd+hsp6F8mC/0lvXw1kxE28qJFFwyIfcM1k7AJjOgL+jjasehO3QrYDr F8IA== X-Forwarded-Encrypted: i=1; AJvYcCV/QTu74phvoEmBScukoMEVmux3TrETd2fgJfrIxDvNKlbIfN10H1C6FqikoUL1so1M9/Iyqi9xkoL50FXHT/5yP1U= X-Gm-Message-State: AOJu0YzOCT2bBwrbgMyHPHIau5I4oyPB1l2YZXG0AwvbXzigA0Qkw7oy 86L7wsFIX6m8hw5YjKi3eOfT6GIlcTBsuqKPDNLdl9oyoE3ExMFNH0RwkgZFT0veCZMI4owVS3W Pa9GClhV+eOGIrJxSQcFwIsYmMtSC1p7dwPnM X-Google-Smtp-Source: AGHT+IFGo95tZ6ajiKJHgB6R635VkbjUHRHen3ZXq710TWUiGCSBTANrhhYRY0IvZJP3YqvVSOi8tJS3g6JTMouiQ/s= X-Received: by 2002:a25:aa83:0:b0:ddd:696a:8656 with SMTP id 3f1490d57ef6-dfa73db3cb5mr529458276.41.1717120575481; Thu, 30 May 2024 18:56:15 -0700 (PDT) MIME-Version: 1.0 References: <039190fb-81da-c9b3-3f33-70069cdb27b0@oppo.com> <20240307140344.4wlumk6zxustylh6@quack3> In-Reply-To: From: Yuanchu Xie Date: Thu, 30 May 2024 18:56:02 -0700 Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony" To: Matthew Wilcox Cc: Chris Li , 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-Rspam-User: X-Stat-Signature: whp3tbd1rs46bqdkpkncjunenwuqybpn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 9D4CC20003 X-HE-Tag: 1717120576-496655 X-HE-Meta: U2FsdGVkX1/8t5iBnd6S9DTaXDdbLlCQMelnC58XDZo9M3sjAxMc8z9OqmoCjxBuFW7exGoXA/a23mLn0UT8+RD2iuCHfFOf3GxWZqbKRfpnCmmQApzv+u1H4idRwsRmQgCudERZEYxp1tIWUT8U9WgWuhQ99rspQRV7SNHuKhEzWp2UOFIIZNEtQ9CAmdeGMne5SnRIOw4QkgBXQv+Cy5W/bBm/PubKpbqir6fp1yq8zAgJIeMAtCmD2VcAMJRdUQPYLwErc8Hn/xroU2UINqKKwG2e6U+KpTbylNp+3ed4OCCOKQnOPnF7s4HBr0qfFY1cFjLJVBoBmQaQ91R7MiE2wvkY9mzvkwqecwH57TgZsseIqSpyilfxM6HiAnvM9SUxLbIHOjodgc52hVDwzTnpMZa4cPBUPMEbRTNTYtCklH+GJ+QjUrcArW4mQAFG2qUo+IPOxez1Sd2a3rTTGapjIXvZq4iNNy+Hwu873vO4nmeX+Y0xbBmI5n8StSXM2+aJPyqD9rUfCK4PsGhso4ziNnsRBnrNrJYMx6m8o/GzHhAwCgxLx7kvLMNrBxKdIcP6Ix0HlOTds2eUIXyZViO6vxMXN2XO4N1g7nRm0Sk1eoVvuXZs1fvgEx3JvlCZ/kYEAx8QYOLCBIklDb+mUTfdnreqY3A9z2gDfMn09/za/o9jIgy51qzAfhhnMKKpW2Arsc+5bKK/uAifF/zgg/+y7EmyDIAwmCleva4N2wijgsIBhlC0XJIWApWQqRny+qKukzUEqA+I1nphsySxjDU9q9G/tINb584AmKZdSGQZ2hg3zYdV9vzagcE7CaRncB4Lo2t43yx4eQjPPLFct5D8Xs2kogalZm/qlfaOigHc+59e7jYZKUo6lAzeP548Z2fNEUE9a8UqkKcBmFjBdiWxBegC/WHVuBU/sIwR9BZ34YPQR36D4lRQ81TnfuBNhNqiwQHV3TYGyLVtLHU TnlG5vKZ KIQlmfEYz1/JJ3Mf3QvpIb74RAeDIPm+quEfVQoh3fgGynPzHfxseYUVexSdE7Ojevg3hDuQk/rxz3HOC0qR4yemHg9NcCHztTXkCBkfNBTKVtZqsmQ0MfC3h+o5Xzd7DamSwp7CpdPiVG6zWDKAI+pQy8NJTurw1+3SnDrXJSWhtv6n73vDPGrGHsHyrEk7d9Dt2lYQ3cMy8lMTiY9w1pHQP/YJSn0PmciRfa48N6fLaNB3tejBdXtR+yYEhMURfhtcSZLRIiQIMvUEtcyCGh5x6O2oGI/2px6JEu5pe+yUhgHFmfv0evq33swhCljmXQz7n 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, 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 sc= an > > > is 40x faster: > > > https://lore.kernel.org/linux-mm/ZTc7SHQ4RbPkD3eZ@casper.infradead.or= g/ > > > > That simulation assumes the page struct has access to information alrea= dy. > > On the physical CPU level, the access bit is from the PTE. If you scan > > 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 need > > 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-fault > 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. 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.