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 C5644C54798 for ; Fri, 8 Mar 2024 00:53:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4245C6B02E8; Thu, 7 Mar 2024 19:53:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D26C6B02E9; Thu, 7 Mar 2024 19:53:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 299A06B02EA; Thu, 7 Mar 2024 19:53:46 -0500 (EST) 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 1B99C6B02E8 for ; Thu, 7 Mar 2024 19:53:46 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B2CF91408E1 for ; Fri, 8 Mar 2024 00:53:45 +0000 (UTC) X-FDA: 81872049210.14.44E9CF7 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf07.hostedemail.com (Postfix) with ESMTP id E34DB40014 for ; Fri, 8 Mar 2024 00:53:42 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="mm/igi8j"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709859222; 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=G1p6GSrc2FPq3Kkmkljo+Z+mwx3RnwmMQRZrBa/Zsss=; b=bpxl+/dP/cXyfWrGEk3534e/HGtHLnI5SkEhoOnlfi1aS2N3CTsMJWrah5AqjjN++9RRyE xGgTfsp0go5JoCVQ4Z6s7KsCkC1gjehdOiRrr5UejzxqNS19Y5vg3Vl6w6vd9aJwAPecTw 0R8P5/BRwyukr4StsFkz9xe6A7R37P4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="mm/igi8j"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709859222; a=rsa-sha256; cv=none; b=oVHQv770SQSb7A8oUWRlvCd/2HuEe9euSqc7T+WPEKmCMNEjYpbVKrFYGAoVguPB1AG1pb PGhhsfDHz/1D6LghYCJ7fGFSdidJwgYCeNv5oh9/Ptdi+b4LdauTMBbixMDtmk6Z5A3D+c f6UtX0QQdv5FF7NxTgW1I1J8ziKxFzA= Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-47310400a8dso32558137.1 for ; Thu, 07 Mar 2024 16:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709859222; x=1710464022; 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=G1p6GSrc2FPq3Kkmkljo+Z+mwx3RnwmMQRZrBa/Zsss=; b=mm/igi8j3LP8w/5CrXzVso7vwRU7vpC7RYKbGjrAK9Ea0qhOlP6PtH2yNCw9h8bK6X 66nDiceAK6mfpcEuAcFJaUKRJ/o2EK9U050K76Uu59gXaMw8rl2hBDqOc6XOFhTtd6yE 2IXaWWJpukgRSVV0hXjXSXgIfHvVjZEAoWdd6CuruGJL3Lrwk3l3BfaN+YglRevYWYO4 iL0LBH0ZyYGoPNuUCA4D6tuDfuslenfmSAHXI3C6Z1FckuOvgJwVKUrUr4r31l84giZy tb/8Oy/Aou92Ry7r0d8ORRr0/8j4etoGqtwm8WQmIwJ1uIFWuR35MuoKDZRU+5tGaquo Uk9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709859222; x=1710464022; 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=G1p6GSrc2FPq3Kkmkljo+Z+mwx3RnwmMQRZrBa/Zsss=; b=VvE8oej6AJJqdZ3qjE75YrHqZl5naFyxV2Q+a7hwVdnoeCtEv0Gana8nxQEnzidJhM dv3tPpREZoFM4hnz54itdSxcFoIVa6+USHMRpCPn/fWXc87CyICo2kwjedW2Sl4C4VOu 9r2YdOFRgoiq8+Kzp+KzsDYhq6XK61qc1Mouy3hfCtXC7beHRcZmSo+Ctotb0EQ33r3B W9rOdQ/QRfULLDiPpXl9WkHVE6Rhz7vcZMnvyI9JkCSxWmOHRU7WfvxDCjwqfsV+rydF KHi9UNz+B66CkdToM3HsA8vGmbiFxFYSS5ouLXTIz+JeABP4spw6oN2F0Fv3RZVZG+t6 0ZSg== X-Forwarded-Encrypted: i=1; AJvYcCXDyrz92EYF6oS8Uq53s0WoK1dcZQsn9LTFIs6Smyvyh2VDUplsM3NwBTu2WNmnZyN50SkpWS81A/NtYBxonyOOlaI= X-Gm-Message-State: AOJu0YwI+6ZLFftoVP5KagJoJw1bzR7SuRSkYRuiJo7BfyhVw4CvKMHk 0OhPGRmrMloXnXQcf+FstXhxV9IfGNtU+0exotJ4PXwPb9ohSHAVs8X8vPYaNHpY++wk8SqT/F3 PL0F6tjprJWwLbQEEhurWvCljGfU= X-Google-Smtp-Source: AGHT+IGa7vtBVEIdz80ol2HSDOLoe8dYiYNgN/2Nk0OSZIy40ATRYx5cTfNMYDFAt+Tye/2gzh+XnJrfy3HZ7BNwKt8= X-Received: by 2002:a67:be19:0:b0:472:5e97:4e81 with SMTP id x25-20020a67be19000000b004725e974e81mr9494521vsq.5.1709859222057; Thu, 07 Mar 2024 16:53:42 -0800 (PST) MIME-Version: 1.0 References: <039190fb-81da-c9b3-3f33-70069cdb27b0@oppo.com> <20240307140344.4wlumk6zxustylh6@quack3> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Fri, 8 Mar 2024 13:53:30 +1300 Message-ID: Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony" To: Jared Hulbert Cc: Jan Kara , Chuanhua Han , Chris Li , linux-mm , lsf-pc@lists.linux-foundation.org, ryan.roberts@arm.com, david@redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: phdoxqhgxmnmtgup48xatryq5dhejej6 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E34DB40014 X-HE-Tag: 1709859222-814630 X-HE-Meta: U2FsdGVkX1+V56bBXPyKkp048b9LygLzEL8MxiLdlLdU4F4umABw4IR3c+XI1w6E5cNS4CZnaKawUNCK9TyLABmosNSq5iilRxVuVZLRO7vNCU2hqF+88A5kUn2n/zM3ljBk9Ft7e5H39Dj75bTMPC0LqvMRquXQBsmfaynctLMjsi6zVH4GkDuKznDupm6dEnf2/cCv0dD83TAGFu/Eh5QVCKiG1/V4B4pHFZS/1sR7tqxJRlhEBg6BMLMwUzwa8cohQSM+V8u7vsmqIr0awJx7bwMjtqrA90WbAUNg13QRTWz5mMIR70l8aWlz9fV9pqgA2J7Bjd4nafywPtckOyzZzyRLlnUCtb2qU1MvIdnijrqnMcZca1Adc6wTb3z/FkYUAnMdwRr/eTZOOsyuatRV4tHgPCLvxr3C7WYR1H1Ywx0IXUfIs6QRXOO6aqVdsoQq5aFAvT9NrXiucuc6IoKHSUy5NDG38nyXVg9jtK3/fJF7zkzNJgVKdhrLHIpVPImMyORk+QZjajZvbWcvPMpdAA+9RLecE32UpvJypAxA84UF3LkTB5c1bSv85JRG4btFodmVNXW6h2PzucuUCq11CCEX26QZCxuQEYpQh0xjy2X5tSTJ028V5wEzQK7xPq6KmcN/9zE5ncaAkLdnsjq83QitH09KXJF5wPSUotNppA9zYNWy/BUH6tnr43WEh1UaIkPVn6pXrmtR30U82qw4ASRHAXTX7i0LnUN6oXQyfCZHKm1gqiGc4ipoPAF8h7RVzFDEMOSm6fb7zsFco36q4tpfpAUb/5e+wlq5Vc+tCSf4ZvuRkiQJmbFHuea+S0X8qBjV3i6NjGVYFUNxe0BnSTvyx1l9PLnJztoHnCAsY6vKbw4NckAp7AlgxhlMvMWcgr8omteq0cPlVRkyJOiRdJlBcAWoVi/fkR6JegvzoKzvrYk1Y3b6FYheyMdNyI5jKp5fVFnwxT0RQWB OmGdNNsL PxSL+YYQsEb6yUZqgGH6hMeMXTP/orb1KTkQ7KpCqRJj2mw/mjlpANmIi/dWeBO4yeA04icXTXfa5I1FmsthFB+uudDbYWESqZKDDkfhDTfLDBMq8ZOb2P5kl5gQlwlIJx/EHq96jetiv0++/YnxliJS+VweYZS+3c0kwxf2QEdjaT19Y/9Q2bbnl+ccHavwCODdYh9ARwrgafrx8ICwDyh3gdoeBK3hq4RuqV102uSAgYNeZl1oc+6YcNI7+QfuLfbwW4v+QXVVyf7lG1EtRoMncPIicidRtvQdDdwL50nrzzadafHaYYnbEKp5NzvJ6r2OLgYhs2DlLsU3bhsrrGRMNz71zyuuRakbduaNlvtKe+HTXhiaQUKZn8A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.003343, 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 Fri, Mar 8, 2024 at 1:15=E2=80=AFPM Jared Hulbert wr= ote: > > On Thu, Mar 7, 2024 at 1:17=E2=80=AFPM Barry Song <21cnbao@gmail.com> wro= te: > > > > I don't understand why we need this level of complexity. All we need to= know > > are the offsets during pageout. After that, the large folio is > > destroyed, and all > > offsets are stored in page table entries (PTEs) or xa. Swap-in doesn't = depend > > on a complex file system; it can make its own decision on how to swap-i= n > > based on the values it reads from PTEs. > > > > Swap-in doesn't need to know whether the swapped-out folio was large or= not. > > Right if the folio was broken down to individual pages on swap out > then individual pages PTEs know where the data is. So I agree it's not > necessary. Hi Jared, My point is that even if we fail to obtain contiguous swap offsets, there's no need to split large folios into smaller ones. We only need to temporarily record discontiguous offsets for each subpage, then proceed with pageout and try_to_unmap_one. After this process, the lifecycle of the large folio is complete. Once the pageout and try_to_unmap_one operations are done, the folio is no longer present, and the related offset information in memory can also be cleared. So, I'd like to concentrate on how to record that offset information and pe= rform anti-fragmentation in the swap system. I don't understand why we should get a complex fs involved here. > > But the folio was destroyed. We want to recreate the folio on swap in? ID= K Indeed, the primary purpose of swap-out is to release the folio (or "release" it to the buddy system). Before doing so, we store offsets in Page Table Entries (PTEs) or xa in try_to_unmap_one. Swap-in already has all the necessary information to retrieve its memory from the swapfile. Sorry I abused the word "destroy", I meant "release". > > \What if you flip the argument? The complexity of the file path exists > already... If swap didn't exist could we justify adding the > duplicated (albeit simpler) functionality of swap? I don't quite get your point. Can you please give a concrete example? Thanks Barry