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 99849C5B543 for ; Fri, 30 May 2025 16:55:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3282E6B0152; Fri, 30 May 2025 12:55:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B10C6B0157; Fri, 30 May 2025 12:55:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 152906B016F; Fri, 30 May 2025 12:55:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E6F8C6B0152 for ; Fri, 30 May 2025 12:55:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AF1DABE8DA for ; Fri, 30 May 2025 16:55:07 +0000 (UTC) X-FDA: 83500174254.28.9910D0B Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com [209.85.210.52]) by imf01.hostedemail.com (Postfix) with ESMTP id C950C4000B for ; Fri, 30 May 2025 16:55:05 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P+NMzxh9; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748624105; 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=yqt2OZU765DZ4rzjJVIwHCfM6JfixmePMf24eq1pAoU=; b=Of2NhgnvLi9Z2d1iQkoW2UD8Mv9RDAjhrFsaptI/J7LYvUIbDWTnpFLWEMgIgDYNk73wNg 8gemOwvIgmWfUuqqqxCWL92yJnWEQfC6lEr2LnuecmfoY5art9kK3SMPjA/hdGq5hp5AZG YT12oI5z5cprnavfi2H15e1GZ0aOMkg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P+NMzxh9; spf=pass (imf01.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.210.52 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748624105; a=rsa-sha256; cv=none; b=P7X3ZyMww9vnokd7J+SkpSO7fNaKh/xWBXxnuey42c4rZ3/oh/JDdsTTq7G03MiJsJ8MDI bY4uyyC7Ym+0XIl029irBlq1NJ2U91EsC1EUEakc2OtrhjMTLnt6QMIeSsSzXgijov9g60 QXiZ9CmV52fUdTMi12iMSOgCMLuq9ls= Received: by mail-ot1-f52.google.com with SMTP id 46e09a7af769-7311a8bb581so1926076a34.0 for ; Fri, 30 May 2025 09:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1748624105; x=1749228905; 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=yqt2OZU765DZ4rzjJVIwHCfM6JfixmePMf24eq1pAoU=; b=P+NMzxh9/3ayl734bE9XnuyfuH82dDYwo6iBryN1ytrxzxYNrFuSUJzvLWa7fF183p hc6ii6vsCA6XTMhbwtEy5T8PkDqoUBrewkiD5kW0ACQ2f62IbbU863bESO7OxUchj3m3 gbw4tWuhA3nsF3PaZEAVtQER3lYulvnYf+dJLWOtvRVnBACGwnOV359ShUen04nWSfqx 2r8yAbguZEGQxRSah0PRc6E1IFEHT3GtHElxFnQ5tWHMf3sfK09OoKTfHRHeJGCqs/eI Dpd892As6zKBfv2McDiB0e1C6VeTVNn8yCmgY0Hozx1SVO3nOtVRrWpvgHH4FUU7p6wz N3Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748624105; x=1749228905; 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=yqt2OZU765DZ4rzjJVIwHCfM6JfixmePMf24eq1pAoU=; b=dPNooM40U2LU1foT4dEOUWBXSkDBi4fAxiI2SI6k5JtFCfPUEMNoNYbVO2DdK9mKKn RC6xwA818Z4/7LDsr6mBDbPEHwblXFTWSCxRamb0VCUi9R79sizGBzdJ3akG2XCUYFKE XMTDbAla6KYm7elt1u/jdF65zRyjBLWAQvwH52ofpzRN+Su4IHV2W12OcFyGC7uI+rnN 9cNQ1E2C+JFY65PdeilRi8bCTwDv5I+9TdBO3u4oYp/stYBfHuDL5aAtY+3qUdjTVHgz Zx8E3jPUqs+e2zFTip5tdxQekt3wVLVW5zZFb+C6N3uvvL9EQFp1rd9UZcNa5KpkcJjp umYw== X-Gm-Message-State: AOJu0YycfJ475RFbKis4afSJXkCtrb80j/VGtmp7deln4c34kTCB1g2L Sw1H/BlJpWbtg4qKcZoFceHTDuFduIURkcTHSxaX0DXGqwrYBS/+XjaPLmLiWYL8N65n8Roa0fp nc+6DJJeGZ3xV8Me7Ov8tjz29H1g61MQvFLL+ X-Gm-Gg: ASbGncsbFStSTBJ97NaV2gAKt1W2Bm77El+/BH5FfghMQX1qaai+lj93Dcpe4UC7cc7 +pOk1O77IMikLYBknotUUsFu1nOIndTJFarkoHp/3Zuk9coJ7MAwrCy65Tp6KC/tgagVGksG5UK Pu2Rhyfvdaft5cpt91l8sARGlQdcw6YnbCmg== X-Google-Smtp-Source: AGHT+IHB0e8ZcQXlRKbX6QjqNRoTic5+x0faxw9bYJUhQp/G7HvCR9DNNLXqmpwx/q9vbFD33Zly4TA6kqaRhd5hL6I= X-Received: by 2002:ad4:5de9:0:b0:6e8:9e9c:d20f with SMTP id 6a1803df08f44-6faceba7f22mr65787346d6.21.1748624094334; Fri, 30 May 2025 09:54:54 -0700 (PDT) MIME-Version: 1.0 References: <20250429233848.3093350-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Fri, 30 May 2025 09:54:43 -0700 X-Gm-Features: AX0GCFvuULRfRySClBlmZxkqSsY-BA5dnNbFR6m80KNAo7UsLs27pGm5GgleJLM Message-ID: Subject: Re: [RFC PATCH v2 00/18] Virtual Swap Space To: YoungJun Park Cc: linux-mm@kvack.org, akpm@linux-foundation.org, hannes@cmpxchg.org, hughd@google.com, yosry.ahmed@linux.dev, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, len.brown@intel.com, chengming.zhou@linux.dev, kasong@tencent.com, chrisl@kernel.org, huang.ying.caritas@gmail.com, ryan.roberts@arm.com, viro@zeniv.linux.org.uk, baohua@kernel.org, osalvador@suse.de, lorenzo.stoakes@oracle.com, christophe.leroy@csgroup.eu, pavel@kernel.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-pm@vger.kernel.org, peterx@redhat.com, gunho.lee@lge.com, taejoon.song@lge.com, iamjoonsoo.kim@lge.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C950C4000B X-Stat-Signature: fyt3grjwjk1wrok8tsa674goxsgiq8oj X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1748624105-177588 X-HE-Meta: U2FsdGVkX18r1Qlj/3kBJCZCzDlbDrQPi5gbfQhwtgSO4jMG62lVzfWTV+zKpBQzpLM95fbO9aG4sI1qBtZRPHHS2YhMUy5auQrKbRNKcWi3J53Z6vh5hRjMdL2dqDxo28CIOILu1yAq0mmFBYE/Kp1KxWEKiOstEZbp8J4MynuEJcrLU6VTr6GAtg9KYm3ADIkS/0tn9PwBtiRKASB6jgr0gawmgiJ1f2dmoR/k8kVkKeMUmZ54hGhNoqolFM8EP1ofQtrJ+e1LZpg3cQDeONIEMfuRZolULcAlwAlkbnK3eyCXXCboen0x4/9IxoLbht628wmqmFVqD61n52/ZZojoN4L0Wdc6SNF0Q/p64OFKJfm/KRD9ovoIIigZMUo2AIPlVgTRlEh29O6yUacdE2uUUuCg+44ostSXNfIHGKBnryuIHEBWo0/q/DKN1frefLsJeEP88hGCrygAfiXqJyfjZfpUZDvV4pumadHt+tWqPW3M3MfNRGgVL7TgkJNgN4pJ3dTiq2wOUDkGm7JQKv8xoFQ2MQ1uNMBI8AvmOKI7s9I5YrrInBOhVyry0EhxsDguQjTKFw0vhNKO2QryIn+Kli5j9QLKA/+tjjv3eVPYDoBQj/ooxrk1SS81TG9zCDfXEzEfslkIjvJPXbKhZzVtAN6hxz4H6ekiWLbIX/OZKA6Mkihj8FgUK2MaAF0f3T0WbAvTZMnDZlnApQH/dFAhfCm2N8o2E461x6TQOCA1fPXC7M1Pa0AbiIZxMFBzTP2/wmhjGRMkLI77YMtmj+sqvCLhDO4IjvchaGxF1gQkK6BaJD6+Nx/GZghQUqJ3++8Vmjw7Pg797WaPRY9Ar3V3yku1f3oo6X5vwo1VdcW2yS3j2QYGgTae5b0wCmj9gRjoZerOaQsbQkcGxv8rK1z3qQ0TUhzFsXlLw5uPGG5jSf4Nt65OWHpfzeXEsnVmaA69MMWnoJlV8ik32+0 xZZcwmQF Fx3QLIY5FYZUtb171UJlgna2Yx1ifSBkqzSpEFVAmHvsuk+4dB3Wms5NOjVmcfHPiy+dyOo2wj+J7pTT1yQOz/piFYXJR5gzQ6rEIjmb35qLeboiyUDSYmRSdTI5knIL0O+/fCvcuRQacdaJTJLNAm40DCAToYFT4eyLm58NvA5Y79Goq4ST4lS7IXJvrJh0iNVQeOA2gruZ4rG7Qx5LYEIt0eK9bonVobHSQKDfCEC8yp0ox/9XPAYCvXFPRT2S5whB7YbiFpAR5NcI56I5JuFBlnv+39Wzl0iQvzycRpIFdtlOPyxOQNDratdzyE7mevbT/aMrZISOzC+gkETfXmQwnpkgr3awDdgYLNcfIZCcEsBkud4t3UzPlK1JNli8WzT3SAj3FSCHsxYEC751NPpyeBBk7A+1ffymYZ2WyoLZZGMLNYzBRjdZBBA== 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 Fri, May 30, 2025 at 9:52=E2=80=AFAM Nhat Pham wrote= : > > On Thu, May 29, 2025 at 11:47=E2=80=AFPM YoungJun Park wrote: > > > > On Tue, Apr 29, 2025 at 04:38:28PM -0700, Nhat Pham wrote: > > > Changelog: > > > * v2: > > > * Use a single atomic type (swap_refs) for reference counting > > > purpose. This brings the size of the swap descriptor from 64 = KB > > > down to 48 KB (25% reduction). Suggested by Yosry Ahmed. > > > * Zeromap bitmap is removed in the virtual swap implementation. > > > This saves one bit per phyiscal swapfile slot. > > > * Rearrange the patches and the code change to make things more > > > reviewable. Suggested by Johannes Weiner. > > > * Update the cover letter a bit. > > > > Hi Nhat, > > > > Thank you for sharing this patch series. > > I=E2=80=99ve read through it with great interest. > > > > I=E2=80=99m part of a kernel team working on features related to multi-= tier swapping, > > and this patch set appears quite relevant > > to our ongoing discussions and early-stage implementation. > > May I ask - what's the use case you're thinking of here? Remote swapping? > > > > > I had a couple of questions regarding the future direction. > > > > > * Multi-tier swapping (as mentioned in [5]), with transparent > > > transferring (promotion/demotion) of pages across tiers (see [8] an= d > > > [9]). Similar to swapoff, with the old design we would need to > > > perform the expensive page table walk. > > > > Based on the discussion in [5], it seems there was some exploration > > around enabling per-cgroup selection of multiple tiers. > > Do you envision the current design evolving in a similar direction > > to those past discussions, or is there a different direction you're aim= ing for? To be extra clear, I don't have an issue with a cgroup-based interface for swap tiering like that. I think the only objections at the time is we do not really have a use case in mind? > > IIRC, that past design focused on the interface aspect of the problem, > but never actually touched the mechanism to implement a multi-tier > swapping solution. > > The simple reason is it's impossible, or at least highly inefficient > to do it in the current design, i.e without virtualizing swap. Storing > the physical swap location in PTEs means that changing the swap > backend requires a full page table walk to update all the PTEs that > refer to the old physical swap location. So you have to pick your > poison - either: > > 1. Pick your backend at swap out time, and never change it. You might > not have sufficient information to decide at that time. It prevents > you from adapting to the change in workload dynamics and working set - > the access frequency of pages might change, so their physical location > should change accordingly. > > 2. Reserve the space in every tier, and associate them with the same > handle. This is kinda what zswap is doing. It is space efficient, and > create a lot of operational issues in production. s/efficient/inefficient >