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 6AEF4C3DA61 for ; Mon, 29 Jul 2024 04:49:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDA4A6B009A; Mon, 29 Jul 2024 00:49:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8A386B009B; Mon, 29 Jul 2024 00:49:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D78CC6B009E; Mon, 29 Jul 2024 00:49:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B8F746B009A for ; Mon, 29 Jul 2024 00:49:46 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3EA8540348 for ; Mon, 29 Jul 2024 04:49:46 +0000 (UTC) X-FDA: 82391562372.29.85CC7EA Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by imf14.hostedemail.com (Postfix) with ESMTP id 7DABB10001D for ; Mon, 29 Jul 2024 04:49:44 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=M3vAfGC2; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@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=1722228531; 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=H2KfcWX4KbJ81LM4EXKwwWqkcKVjndWUDZFzO/J9RSc=; b=Cq0NatcHbrGpumv2yDtLLJiABbdWQO4b4Vi1l9B8C+kQmJp6dVnDv8/J1TBMV9aNav65t/ JLh0my9icDpizooEB6LhiEst6B9+xxgjpmWE4NAGqoMCXhgaozClbFQlVxlSh1xpXaKiCl OXlwIoluQNPHibBgkmBSOcvcW+IKSBg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722228531; a=rsa-sha256; cv=none; b=t+EzhMBxQCPwN3ioRBtIZMeAE8SSbGuhoP/oW/SlH1HDOorzolA4Bdlnuv+eVsRTBlVZ2K Lhw9hFGZ3Umy2+3w8c4ryue9hBqgHPCzOj0LrhMS8mKoofQdKn8/Gplo0rEnUEGq3UCqME GZ/aauLy5346kzdQvHCE5PwJfe7OMGE= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=M3vAfGC2; spf=pass (imf14.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.176 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4f6be9d13cdso697551e0c.3 for ; Sun, 28 Jul 2024 21:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722228583; x=1722833383; 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=H2KfcWX4KbJ81LM4EXKwwWqkcKVjndWUDZFzO/J9RSc=; b=M3vAfGC2cZYC6Uo7FVWP/Wi//8UWiKENClZcUdlmL4vERcYLNbfVqWBwdQkztHjD2M hpB4QQaaYZjH+WFjyhA0pe/9VfAJLI9HydegeOytU+FO6wvT9GD3ULcIhw7nc36/ZNM/ 8UECRZzvgTWXqIa/EEniLVEoEsMojMFMaz8AURMIuWa3C+OpbChOrmR9sadqIcz0L/Vs KcpC3ZohvLHMa3QXEYDbVVpWy88oRcvmX6YyyCKMEztA3eOwG2w3ntPQRL0chHCL7Iiu McbR/w3/Xt7T8exeaqJddMyrqvonYal+XF2E+K8LG/a1iw2yJDxuX1lXXJPdOmCYW5Di R7YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722228583; x=1722833383; 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=H2KfcWX4KbJ81LM4EXKwwWqkcKVjndWUDZFzO/J9RSc=; b=JhucBgcRY1GVqg2tvx5bDNbNPzu4BSKTa/ejmqnqdKvwbsxmk78Ekxx5H99zTiBZwd //bNVN6CijRinK2JxRAiWisnla67Une3cmNyCSF7LCOEqtCrb7a5cbFOcmlai6jNFOqD +UHl4MaweBOACsk1cbXFcQSS8WntdwV9qslCbVzT615Et/9j7T0qXccyPsH+ot4aUl7H ytgVNnxOcMQAPIDdpsSa5/KE1/jFNa48bMYAsJZJ5vQd2nCeqYF6wQhnY491B2f7xpoK HwRCmtifheRtBVvZFXlhVfnH0XOGuBSz9hDWS6VjiOH8hRtdNIzmDpDqxMNSktlIfSmz bYrA== X-Forwarded-Encrypted: i=1; AJvYcCWt7zFQsAjGfTNVkvBjQ2hP43kxzEv6EqAOSXy2e9hJiKXvYcPBmmPfz++TnJR3ZnuoOTc5r02MUbcN0KVYfizb2XY= X-Gm-Message-State: AOJu0Yy4VrLoxxZSzCyLA46axz8UrmnETfLj8kS083g5UjwnChMEP94n jNQeSz/xoOKgz+MbX+wILak46c5yB5hdZ4oKTBMc3kmoc92XWdPRc2nEi8OTPLuCSB9yW/19PA7 o3bJlU8R1T/fSdhJ2133UylQFDX8= X-Google-Smtp-Source: AGHT+IFIXnVcPdK/uT50Iqdy1PDwCx0e3bFHORUL/8NjLqKj2HaLltLYHo9eR9U+7kClMyBEe83zDS+8BczIH8pCD+0= X-Received: by 2002:a05:6122:3b0d:b0:4f5:1363:8445 with SMTP id 71dfb90a1353d-4f6e68e1eb7mr1876725e0c.7.1722228583450; Sun, 28 Jul 2024 21:49:43 -0700 (PDT) MIME-Version: 1.0 References: <20240726094618.401593-1-21cnbao@gmail.com> <20240726094618.401593-5-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 29 Jul 2024 16:49:32 +1200 Message-ID: Subject: Re: [PATCH v5 4/4] mm: Introduce per-thpsize swapin control policy To: Matthew Wilcox Cc: 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, 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-Stat-Signature: uzsbb1bbwm9eibqmuow1rwz85581uedz X-Rspamd-Queue-Id: 7DABB10001D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1722228584-454819 X-HE-Meta: U2FsdGVkX1/iyEaYBitsswDxzIwBOt2/Yr0CDfP8bKgSl1k78yfvLqM10/IY4wXbhGkyfTnqPkJP/g4z6r7/mSBwC8Y1ZD0BeqbDROHU+YPcu2KtxUdalAsL1mH4wG48+UZVzzoRZbOkEzK8zv8Gesek4xjt92LCe/5jlupA8+FM6rQp30bHcnAoTErwSm2iLxxqznLcTZVFcFRoKepvjbyHldXaxD96DJVBB9gb6cbbu/H7qZHpRmdDIkXqaexGPZus4NFYEY/503KHULDvMq6nJZKFYCm2eYN5NfghEuyJmbATgruDtvoMthZ+m/1rBozTFb/Kg3jfIPkpZ/2reALv6gK/+59Yd2ICFESO188B0b6x9cBQah6jcPFAZuvFfgftEHdK/vhnhOFFbrFuFTHiDKSDs6/KzMl6SdyoG6bsghhe2++cpxeCh3simz4OFa+MLfAnKrg0RcRfa2DyDnpKF9Xn9eqw1Zkmbev/vR9bcLlc6MIk459lYm2864k9Hr3TZQo4xhOl1Tyo7bEcbNwHHuzAVL3jZTFpz/eyz24U+po8I/22dQ1NWiU7T9xlP4IyETBxTnVZgYLlJ64EYHSoRdGdFraIuxZ4kyuvSsWk1I7q9sW2kgjfCIowApXfZI7FR255fWxAVj7xA0paYdq6WB5+8R1sO6ZIr7vNfQMrUqTLqxR6xpJJyOAePeFFsn7/bjxvvbjoaIABlq3muEG47xwi4Li3mcMZEPaLqP9oI6/qgCmlTS7Crt9cpaUQdQHUpUpxDU31CdSUo7E7z8tgejz+SQCB4uarWXu3Fog/YqBU6ult+ieZznLzNYyd3VCKa9Ag1vgjICeLGKlvxJBOJYbBFx9IxbMTKZmVsN33NgjJlvRg2dOxlOAs98Y9Z7p8pY87c4cUJz0vLUbtm5+VqheHxYRcfA3wJimiswQnth1OJIq7jVuw189M7Uyax3fkoOuf/l0ji2Eg5Ah JUjMsfOv HjZMssMeCrU17mjFWpZdz9G4VOv7LW8LercKxyT3zq82Uijz7dmLMRH3jvXPEq2/JTRFxLxaOUp4Ad1JrUaDUY0Q9Bce3gcBBVkgRxqpcQeVRrsL8LfJ9H6h/h/FQq+T7//4VmHjf3QIocD0LOWJ+EfIeuBtnijuAPdlRJPDjnepI+avjIxu3r6W9foSYMjYClqLvzIrWCzbDJN9b2Q2BWKL0CgduXpLt0n27eShTS34+DnZ3hMcVpCT1ARQvmVojZEyYcHiET+3tldpcu2gMULyUp4MrtimeILIT+dyyBHuryW4Jgt1gJrth7hIgfygpHxCENkQh0Pb8AQH1KpD+qnrDz9opI5kMRFRqItlVcsaagVE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000092, 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 Mon, Jul 29, 2024 at 3:52=E2=80=AFPM Matthew Wilcox wrote: > > On Fri, Jul 26, 2024 at 09:46:18PM +1200, Barry Song wrote: > > A user space interface can be implemented to select different swap-in > > order policies, similar to the mTHP allocation order policy. We need > > a distinct policy because the performance characteristics of memory > > allocation differ significantly from those of swap-in. For example, > > SSD read speeds can be much slower than memory allocation. With > > policy selection, I believe we can implement mTHP swap-in for > > non-SWAP_SYNCHRONOUS scenarios as well. However, users need to understa= nd > > the implications of their choices. I think that it's better to start > > with at least always never. I believe that we will add auto in the > > future to tune automatically, which can be used as default finally. > > I strongly disagree. Use the same sysctl as the other anonymous memory > allocations. In versions v1-v4, we used the same controls as anonymous memory allocation= s. Ying expressed concerns that this approach isn't always ideal, especially f= or non-zRAM devices, as SSD read speeds can be much slower than memory allocation. I think his concern is reasonable to some extent. However, this patchset only addresses scenarios involving zRAM-like devices and will not impact SSDs. I would like to get Ying's feedback on whether it's acceptable to drop this one in v6. Thanks Barry