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 6DFC5C3DA49 for ; Tue, 30 Jul 2024 19:28:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CCF3E6B007B; Tue, 30 Jul 2024 15:28:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7DFE6B0082; Tue, 30 Jul 2024 15:28:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B44BA6B0083; Tue, 30 Jul 2024 15:28:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 9895D6B007B for ; Tue, 30 Jul 2024 15:28:57 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1067980475 for ; Tue, 30 Jul 2024 19:28:57 +0000 (UTC) X-FDA: 82397406714.07.8217D15 Received: from mail-qv1-f45.google.com (mail-qv1-f45.google.com [209.85.219.45]) by imf12.hostedemail.com (Postfix) with ESMTP id 3794140023 for ; Tue, 30 Jul 2024 19:28:55 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ddzaTPze; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.45 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=1722367707; a=rsa-sha256; cv=none; b=xoiXFPCnAXmPoNRhwhtNaRQXoGsmgvoqa96NK15Y1h82lTvjPyb+HmTsp3IKlUXW6pYgiV R0RURCpYE/VQox05r4KBhVkbBD3dKk410J1FSblLiUGK3cCDsfiR8CBtdj1BrPkqgmcleb UgjQPlPRBbcg1+pdGtgn6mpu43fcFGo= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=ddzaTPze; spf=pass (imf12.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.45 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=1722367707; 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=xS6ru8ScdFhbZFzDx0X4t57s58hjeLhWtmO1pRP7Ink=; b=n4gwNY/sxSQjIDRPvX6Df6qME0Mbn81iTDMMxmjoGDUQFgQR8ksCZpexmVsJFyhZIUysvi ebtOoGm/0GwaLTVLOB+jt20RBLmr93bTSSpVwu0soFaHhUStXJuFEKdQCf8J2vSglBuEyL 2eeJbcsRHXP9D55/qpSF/p9padqXMkk= Received: by mail-qv1-f45.google.com with SMTP id 6a1803df08f44-6b7b28442f9so54440176d6.3 for ; Tue, 30 Jul 2024 12:28:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722367734; x=1722972534; 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=xS6ru8ScdFhbZFzDx0X4t57s58hjeLhWtmO1pRP7Ink=; b=ddzaTPzeu7YP1Sr7oKvgelj8crieKuPI8tn3evAmhLqZRkZNzbK1DDhdZFgEa33xi5 BLmR3L4uH5nfDuPkEoK6LE5aFcxdP3jBSjWLBva5uoD9xYEwmQ1sJbuT0tIOvT4nz4F1 2VzJxJFZPdrbBfKT1JiQkYJHwrIG/P6CBGDVUcRNCIqcmK0ZQV1PJonNG6ZiRPYasMNd CnHpOm+MQ+RWbuzAok35QSDU3B8Q0w2OsTKL5RABbgGrmGx0W1Vz6puI0myskwvjCMXU EmAxWScfMhaQB/lYyDj4BLFrJds1ibWAuRwObad1Jfwbfs4nJOAW4geYZ9eWvJ4tM4QB 4RaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722367734; x=1722972534; 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=xS6ru8ScdFhbZFzDx0X4t57s58hjeLhWtmO1pRP7Ink=; b=QeIc5VB7q0CSQs4e+z1dxrzh0QFkTSLbh/AJLMsglFzVAycSSvAK0JeEXw801Y51ko m10+Ecww8cxhO4PJeuUqZ2oYFsugozKzMqPMmnfWpcxpp6DS3jzeU7syVmBXJlk61h6x NZ2cTvPc+vcQI7UgVMeZqmqjTkcDE4KELjeFx8TMXPvEWBAPVy3oJ+9fBPVMND44MvSM Rrli6mUhKm5l4P7r5SgL9/VK++AVPmgm2WKKx5NrkM7dfTJT8e7HQbKPAhS8UJyYAPVp rTbSs70t+i1mgoLihfSPwcUFmCqrx+JZzSm1iWbyy0NEfKADoDJL0vCMVQWNheepcHh2 3Vag== X-Forwarded-Encrypted: i=1; AJvYcCV9kxt+QZP/D8Cd/yEFKCKMhsuqhpSko9fbVyJtlcavVlLnZLx65PRvCDnVaRbVEayQt8p+M1y70pVxyOTAaVusw60= X-Gm-Message-State: AOJu0YyPR3FJTOVPATfQ75AJ6UW6LPJYG+pqOeTYYUzky3YUWRYdEqc4 VbHHteAo2LGUiwRu7MHltqrhu+5IAq0czHalh9/tFToqmc4ADG5bjYHG+sWpjKUFg7cQisf/Bt1 VfF4Mq4G8EPMO5FDgQzaJTsBhFQE= X-Google-Smtp-Source: AGHT+IHvdzR9AozSVVcmiQnk5x4y4P+7Mq0S4lIBOMzALU/1+3glPBlEGWPSbsgc0/4CHv5UItAyXrL2cDBjy2tXP/k= X-Received: by 2002:a05:6214:21a5:b0:6b5:4a2:79a2 with SMTP id 6a1803df08f44-6bb55a7682emr141211566d6.28.1722367734192; Tue, 30 Jul 2024 12:28:54 -0700 (PDT) MIME-Version: 1.0 References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-5-21cnbao@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 30 Jul 2024 12:28:43 -0700 Message-ID: Subject: Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy To: Christoph Hellwig Cc: Barry Song <21cnbao@gmail.com>, Matthew Wilcox , akpm@linux-foundation.org, linux-mm@kvack.org, ying.huang@intel.com, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, hughd@google.com, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, mhocko@suse.com, minchan@kernel.org, ryan.roberts@arm.com, senozhatsky@chromium.org, shakeel.butt@linux.dev, shy828301@gmail.com, surenb@google.com, v-songbaohua@oppo.com, xiang@kernel.org, yosryahmed@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: pmgiognmwtcsf5dwzy7hx18usopezeus X-Rspamd-Queue-Id: 3794140023 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1722367735-787520 X-HE-Meta: U2FsdGVkX18WbkS/zp9i5ej40JdAetUPTIEQTEq8ipBHDvOIwcGHPd+sM0cu/4LATiAgvRtF6CkofTdiRPpzKMQXy2eQHXNmtNNoLSHGEmsv3jm/7V3+699W8lJVs1qVgtTqJomENr/eyU72U81ahClyvd3/gTs0fzIpGdPolWA0Qqgtgw4amFng4xk1uwVDgD2UdRxtBkJyxhKOI6yGaB63rZv+rQL9acRAie2W9uHtxsS1zB6Rjlxww0gC8PjmoHPGJeAZa/qbadBrb9wC3yA9ERPThmHiql6WO3cNvSCW21NnEJc3nu/UHD+PeimIydFJiT59AVHEqZ0GLpREoPT8m22MpOg1UkznsqVpFLFf3KfSE3/W+r9BK86OKlfzGWBKMZClVqNpM2Ar9WxqHyyq7+3cFNJv5+DWjBjzMNt4+KSGslTokcfJuyiKOif7wjOWyDqxO3DqV9utPvGfVvW8cOK2o3f0mk9B1keUW54zt2qeS0m4wpEkl48QsQ0zpNrHkAqW90a0Xo8Gs4jmebwRY654cER6N+CeKIyaECtpOdjIJSSjtFIydrrPGmQ+7YRapozKw0cCFOTsKkcr0Ab42LFEJ5X4vx5KnBxKiDDM06Ogy7e64AC7KnAiDe0qBfsOg7nAOyVlGvbSHDBgx55l6hgVI+q4oEHyLvjYK5sSO13NXZBlXu2l4BjQLjlxRO/eIalvYV19uDTBIR5caun5hPF7khSncm03s0QcbnHuj7qpRU2TC2gp316GEdBqjZtSLUnJvPjEH2OfstLe4+hlwMfKsiPqGnr+IfS9Hs+89+3Lprgjpo9Bk25Mvuj3ZtpMkrMp0isOXiIeozFULYwImw1MzaLRmwT4O/j0LnesW8U1ftAEeffHk2EQ4mQnXoO5x98aiRien1ESF7EIMzyHly8p+pHp0NXBJsoNGbseRfMfW/lBz3yMp0NeabZRor5s2M4qmu6YAXzokHu wQmHEJk1 cjBTYD0jyZgHPNNVkcPDDe8qm4fjYH7xcODK8zPWy57N9AuHDHQSWqA+jvkDasON9oYdhz/VF/k6DeCqTk60Posto4D2yNHjeW6G+AK1keQ9JHOqGofTKc0ZD0qPjb8/BjY7VJuhypzaOap1KdwbwpCbFGlWi15YoOw5GVa54+JaA+odIFD/9zELZZnAGIurPduv9T0QjqnFGE14GdhyKE0Ss2Xxv3mwci8I3Yy2Fg5tvj+P4B75rNIAxMMZSeqDsJjl1NfIDIm6bgDZ45Hju81nZ3qnnaZBB1wxSTRTxiUVlXthKkcWoxQ06dv/cE2oY6n4GmfdGDDi5ebJ+KDm9d1TscjjcF7W51Bs2Pdd2wjnQ62M= 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 Tue, Jul 30, 2024 at 9:30=E2=80=AFAM Christoph Hellwig wrote: > > > Well, that is the point. zram is a horrible hack that abuses a block > device to implement a feature missing the VM layer. Right now people > have a reason for it because zswap requires a "real" backing device > and that's fine for them and for now. But instead of building VM I completely agree with this assessment. > infrastructure around these kinds of hacks we need to fix the VM > infrastructure. Chris Li has been talking about and working towards > a proper swap abstraction and that needs to happen. I'm also working towards something along this line. My design would add a "virtual" swap ID that will be stored in the page table, and can refer to either a real, storage-backed swap entry, or a zswap entry. zswap can then exist without any backing swap device. There are several additional benefits of this approach: 1. We can optimize swapoff as well - the page table can still refer to the swap ID, but the ID now points to a physical page frame. swapoff code just needs to sever the link from the swap ID to the physical swap entry (which either just requires a swap ID mapping walk, or even faster if we have a reverse mapping mechanism), and update the link to the page frame instead. 2. We can take this opportunity to clean up the swap count code. I'd be happy to collaborate/compare notes :)