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 D5860C3DA64 for ; Thu, 1 Aug 2024 20:56:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6A5CD6B007B; Thu, 1 Aug 2024 16:56:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6565C6B0082; Thu, 1 Aug 2024 16:56:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 544C76B0083; Thu, 1 Aug 2024 16:56:07 -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 3600C6B007B for ; Thu, 1 Aug 2024 16:56:07 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id BE4FCA05AE for ; Thu, 1 Aug 2024 20:56:06 +0000 (UTC) X-FDA: 82404883932.24.B73476D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id B37A2180012 for ; Thu, 1 Aug 2024 20:56:04 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QsMr1FH4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722545700; 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=8CmCqQlYUFhGtSC9ipOc0jQVIxfLrI9uCa80i9yJAoI=; b=7enzJvT7mn88TEooiPMJ/RBXRF6WmPGVg+UKSk8VDx+RE71yyG0yD6gAeziR72zfCbFILa U139Q3VeRA3t8XGsHo0kGC3k2Jw4h19Bdjlt0Mzq5LQweFiGKGVd0Z00vwoPI8fa11ku7D mJi7TTc824RFprOhcZx5IIVs2ONwMnM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722545700; a=rsa-sha256; cv=none; b=pIUw2rtCcbNhoONRB13K6r/N/EmXKDdqW0SgwF/S7pFEOqrlqvOF1K/cI05336MYu3C0av GKdditxCw6lAxO9SYbHRh24QMhczA6rQWj4oteF25hmpIT9kew2OrWKfdkhjYA9gEht+z2 oFXzkbzfz9+y5yaUBttjAmaOWS9jX14= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QsMr1FH4; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A75B16284D for ; Thu, 1 Aug 2024 20:56:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E603C4AF0E for ; Thu, 1 Aug 2024 20:56:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1722545763; bh=sIrnSJw83glUqUNpuUrGKfKjyFNGaOkzu4eYNDdxWRM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=QsMr1FH4fqEHyezoy+ARz1/C9C8f7DI209A0Exz9m/HBPUglDeGslAPKssoacI27d yK5ZbKFnBAd4P5sygcxkWFwHcYT0gq31AGCVynJIJiRCgMhafJiZhvGKwh/Q+hWp4E 4/w1kszZRbM7QFkS93lRe9HVofnMkTq/WadmnvXxpjYyQqhlRvpxaCUG9Z/9BvaIS5 8on965JouoMwUEZYobwcDrmqazGlFIT7qaWu5xlwXsdZLwfvA6yrxgGlJnPgTUUQBe YIttW2bSCdz1RW9f4BE6FLKUUUuaWiaOuyRSLcM0Au+cM+PUUQxg3PElWsOQBgxZtS TtjSIDmrcnSvQ== Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-66108213e88so60723407b3.1 for ; Thu, 01 Aug 2024 13:56:03 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCVLhEvLi/iv6T/0yHYw0sIAJ4ujVCCvVuSKqelRv5RoycWr2mtf3yv9OH2HnbwAF/rtzcil9VDWtNvX3rlgU4z8sAU= X-Gm-Message-State: AOJu0YyWCBnhBAWv+0ikuWb+aKbFM9Hu1ublyzUO6rSPJtCZaD9azXL3 uclDYSurMyvi4+0MDVwRYS8zBlII3k4W7/p+NgZKD6yuIx0s0rjk6KZweE7wnZmx0lVmVhtgboZ U5AqX3S3+e8UCugXSzBPIIR1sBZPffuUYATdrdg== X-Google-Smtp-Source: AGHT+IGBANcF1oiO704BXaP+cr5WZav5BHERyJAT1vW6BA4zxVjL2rmZvMYad1m5ZTWTk2eeh/D3bVG6rLQQJ04fV/A= X-Received: by 2002:a81:c24e:0:b0:631:43e1:6b99 with SMTP id 00721157ae682-689601ab907mr16336177b3.12.1722545762584; Thu, 01 Aug 2024 13:56:02 -0700 (PDT) MIME-Version: 1.0 References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-5-21cnbao@gmail.com> In-Reply-To: From: Chris Li Date: Thu, 1 Aug 2024 13:55:51 -0700 X-Gmail-Original-Message-ID: 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, 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, nphamcs@gmail.com, 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-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B37A2180012 X-Stat-Signature: jh46srykm515b81epspift6e9bgxhqdh X-Rspam-User: X-HE-Tag: 1722545764-250866 X-HE-Meta: U2FsdGVkX18DKNXmkhRxs4OpsVMcQrzaFZLMBj9w1QX09zR4Zqa8oJQMoMZLf2XO7o4vRoH2HivNWCiw9+u/hog0dnMddRyuFjg8+Hdsp556MMoa062Ode3i0aoLzVQ3Gw7DKqcXMUA1kRp1eSA3KxNKnF4u9D0lNPgETonvo5crVOJSCjHZ6aWmdmeLs/QPhMZtRMRd4C62J50MdqlLXv8e8XjPp9dS0AP7G8T6o7zSkvGpKQNc/t3C1i3q2H+FYiz+msniRoSWLhAfDf8JvoVSlqQlbIAuwNqa3b5QHhtvO6tfU6gri0+DDVt5vOtYMGtbkfbcedQnn0gDT/sXeGZI3EWCbENA7xW8HVKQ5vaqwfKj/7S5314Vwzf+QvErZFAIbS1GHQskjs8fwGmg/VN+WkSjkgqFkneHR/XMqHlertEfzcwEY4Gek57uuhNgwXTXujklVPZnKZjsYjw+W1jy9ioawt91Rj2uYYUkBFh93/G3TGhZg3bOQ/EC4THzX+K5U3wxdhzrLWFJpLgGr+KpwjLeAezzLbZHzPg2V3hni49J/GHKkUP2pp9hMA7sYyS3T+BaIBYJbEXPBqloxlZkb3aWn1ydBcABWkFC59vBiLYv+JsU7ZkNKYBMO/P6hwjUBgYWNVDeamwnidc5tUKdTlLClqzVbQn7lFlPIkb/iixLuDTMv0q09OxxlsB+N1yNRMKEJc+rfQu2HN6qDF0Xg7GdIPZJ+6OxUSvYtqjK8fCGwwcIUCReUhf/gqnRQxC/Wv1HelPolnO33yKohOdqPjhKRxsDdfBsPwmp3glCMgdhhI9XzN3TYYgrlnhrnd2sBebOTCcIAW/wrzvSbp8NUZe4jJ4XxnwLU7E6ssCGKNIMubm7LXtdwNpDV567BBHmuf6NANc4x3H45GvJsyJUog9m8KQhE1dqRf5/B5c0wi1IJc+2Au07Z8kD93kqDciTpflj84Xp+nCtvHn Yz4o6+04 TeEV+bw/EsLepDSIOM92ALmBKh4tOw7hFOToGekwaVyKsQRBTDYiDD/8lSPp6C82qKMTCF6sB3ertTS1i8JWqUBaoH7FBQVN5kaT01qPzDiZgelfEsqzJs8JO/gpynDao1SFan/pOXAII/mVg2ok4rOAa+tBBVmsUEjq5kb1XzEgWd46Idw6Ofid/tHVvj/4L4B9ny0oVFuw004Ey3llsJJmF+/1W/F3se3Xb6YUBlvGnFqARMjHnAUyxsVqHXOg8SVuyT3gyVbLFZppuazJrM/484Ei3vDDZXlpry0A+ZwzNya4BeUXgJwsusg== 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: > > On Tue, Jul 30, 2024 at 08:11:16AM +1200, Barry Song wrote: > > > We also really need to stop optimizing for this weird zram case and m= ove > > > people to zswap instead after fixing the various issues. A special > > > block device that isn't really a block device and needs various speci= al > > > hooks isn't the right abstraction for different zwap strategies. > > > > My understanding is zRAM is much more popularly used in embedded > > systems than zswap. I seldomly(or never) hear who is using zswap > > in Android. it seems pointless to force people to move to zswap, in > > embedded systems we don't have a backend real block disk device > > after zswap. > > 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 > 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. Yes, I have been working on the swap allocator for the mTHP usage case. Haven't got to the zswap vs zram yet. Currently there is a feature gap between zswap and zram, so zswap doesn't do all the stuff zram does. For the zswap "real" backend issue, Google has been using the ghost swapfile for many years. That can be one way to get around that. The patch is much smaller than overhauling the swap back end abstraction. Currently Android uses zram and it needs to be the Android team's decision to move from zram to something else. I don't see that happening any time soon. There are practical limitations. Personally I have been using zram as some way to provide a block like device as my goto route for testing the swap stack. I still do an SSD drive swap test, but at the same time I want to reduce the SSD swap usage to avoid the wear on my SSD drive. I already destroyed two of my old HDD drives during the swap testing. The swap random seek is very unfriendly to HDD, not sure who is still using HDD for swap any more. Anyway, removing zram is never a goal of the swap abstraction because I am still using it. We can start with reducing the feature gap between zswap and ZRAM. The end of the day, it is the Android team's call using zram or not. Chris