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 5A6F7C27C4F for ; Tue, 11 Jun 2024 00:23:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC8EA6B007B; Mon, 10 Jun 2024 20:23:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D794B6B0096; Mon, 10 Jun 2024 20:23:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C409D6B009D; Mon, 10 Jun 2024 20:23:55 -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 A605E6B007B for ; Mon, 10 Jun 2024 20:23:55 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5C9A7140FE7 for ; Tue, 11 Jun 2024 00:23:55 +0000 (UTC) X-FDA: 82216710030.07.5794588 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf10.hostedemail.com (Postfix) with ESMTP id 87A2BC000D for ; Tue, 11 Jun 2024 00:23:53 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AOkezhY2; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718065433; a=rsa-sha256; cv=none; b=2KleYgD+yTgfS+7bB10VeWW6SzoilnIbHf5Wg1jEuw9BTaDeahzLSqpP13GqY4It5bwm68 kUb4SXfkDllIB1kHJGTq48/h+IuaC9SF1CO0THBAUkyLGy0G/aa5ROBbeXXbSNP0cBevCn K5qTPZIPvMFOULRYmHdhTv665dYTJP8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AOkezhY2; spf=pass (imf10.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.171 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=1718065433; 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=JBcfZBsNjXqvaaAUgvq2fla2LtZb2+mrlHXG8zrdJMA=; b=N+vtkW6LPX+76HnH//gMhk7Dlvjd69h9wTPuLNRX3Ve1P7g/ANBF01u3xtGeCaMn+1yFnb u8JaXPTAVjUTgcJ/zn3s8uY8TZbw2R46DjEguRqOcar54I7UyNx2gZMD4DUbjLssZZJIBF pmZ/g1KHpJ297nnYa2mbNhOX5Nn7Mxs= Received: by mail-vk1-f171.google.com with SMTP id 71dfb90a1353d-4eb3a7d7bd1so1629110e0c.2 for ; Mon, 10 Jun 2024 17:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718065432; x=1718670232; 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=JBcfZBsNjXqvaaAUgvq2fla2LtZb2+mrlHXG8zrdJMA=; b=AOkezhY2Z8nY4qkhzCynad0tX9uU3ZIg2OmK9BxIaR+kQ6AwJ6UXl9qpVBcT6piZNw unlgsHOBX/2mXbyo+1r27EXkH5IRSPBnAwspzzAR3fcIl3Bp21kGNuBy3UFzI+5Nx9l3 6gznRpvQFmBOwtJFpmHyA0hMrLPmwbWCGpEVbJWlyhSIefuAZCcudmVkz1sUxuKbNeHq B93pTU7tHj0618jolxzp7I+YhHeK+T450bwopZGfZaxwmHvLRqEcZUx2Tl+OI2s9jFqn 6WgCez0uAbLDpX/XMjGexmGcNlxYigTlveQTc0R+2e7RfP7ZJDW1UQjl+7kCKCdif3eD HcKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718065432; x=1718670232; 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=JBcfZBsNjXqvaaAUgvq2fla2LtZb2+mrlHXG8zrdJMA=; b=GOrPDDoaBIp96s+az58VSBpI38VseVnHqcvSCDMKf2iOzxArRHXYrbigSYx3wDvrgH 1ONKK/0tXsHUt+xn7Lr9XaK+GhMX2hky4LsJjC/bX5Eac0tvk8bHFyd5aYD1h4xd/Gqn yxzLd4hnMgyLHoEeFT1MHehQFnK8wnzvlDnjiR4PfLpfv3BEE4COv70aqblXsuoReQu+ FRuc7ofC3cAjHdtptLSAziGPobjjm1W7Ar2zCHStdkNqAV+3gJ6FzimwqTyYGaR+qFiQ oKKLuvr0TYKvHBnfByqy2oUXnLJ2mOdHBezQxq3KJiYmLcWCFQJah1Pm7k/Sc9xAzxYU IZcA== X-Forwarded-Encrypted: i=1; AJvYcCXW6rQR7PQo8mpYFb0JUDj9GbqyYy4eQlspS93mv1J9TgAGXlN+U4dhsFJ+uUexn4dy394HI0J4bh7YF8kma4kcRpg= X-Gm-Message-State: AOJu0YxLuc+Rl7d4IsldLOOp2wN2N+AoClhxSyShx/xAB2V3qf1RkHAa ghzx+l0z4ZxkqP7Koe3YufpMsffuaoH6qUD+Iax0a59IKh+CGLgUAK4I+wAjVKIwVP5rpIFCSbx 8MAmYuCmD0RuYAT58w1TmGtnhs+I= X-Google-Smtp-Source: AGHT+IEPO+fKpPNitn2Hs2H8gwkhPFk5foJ5Gk5K+ob/M5xFOEIWmXKCuDfDSbOu2UxhBupLz0iYAmsjhIV1/rVZDKU= X-Received: by 2002:ac5:c7c4:0:b0:4eb:1b53:47a8 with SMTP id 71dfb90a1353d-4eb562d9602mr8595148e0c.15.1718065432448; Mon, 10 Jun 2024 17:23:52 -0700 (PDT) MIME-Version: 1.0 References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-6-21cnbao@gmail.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Tue, 11 Jun 2024 12:23:41 +1200 Message-ID: Subject: Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole To: Shakeel Butt Cc: Chuanhua Han , Ryan Roberts , akpm@linux-foundation.org, linux-mm@kvack.org, chengming.zhou@linux.dev, chrisl@kernel.org, david@redhat.com, hannes@cmpxchg.org, kasong@tencent.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mhocko@suse.com, nphamcs@gmail.com, shy828301@gmail.com, steven.price@arm.com, surenb@google.com, wangkefeng.wang@huawei.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, Chuanhua Han , Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 7kpre4hddnojcx3d93krh4911aojhsir X-Rspamd-Queue-Id: 87A2BC000D X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1718065433-441045 X-HE-Meta: U2FsdGVkX1/07ZeWUd8mkoF6slcXf3gsLSr7pZ4hOOVjqubASkeSyhjcCi1GhkrEKKDtz60/GVkQuiuXF9NXP62+1fDxu4g7t5A4fKpG4O9Efszwq/7k+pNQ1RFf075L0SbfOS5q4MnsU22WaJ8A7rC2baAwaxYXQP3Z0zaCPyxNjniry+yqnqTGc+rAEq+ws+DuxxMRUjd2KoQ+Fq6SSmgqGcqTdGuZhYcR4UBxfyaJs/Eo/GggR+GnmSms7sAZphQWLhEumbmqWuMuQC+iTfO1WZp4CtgOXdc9/NHqTxuW6qL7+gq2waHNN7bMvJlvOwmfPLMXa6U3TtX21Gm+XLFSVtxl8KIOVOr5AW8dWDJ4bPkZWZHEbUDMNkr4gT3lNn8p/BUbAJnR9MjBwfYWosIkv0gwAFeVlQHcIlYo4cD2jSUgc31OWiU8PWQlQMQmWRPx35LY/4nmjYXMad+0ejaWGJRZ0sK3JrHhjgwCwB4RB9/FdUnTcfP4s2bY92jQOycBgmTzgVn5SpQNuSdZgxRrAqdNlr6LtoV9JHhDkl+vs6C+2nYcDCvNLOvMwsnu6dKRLtvsaWBW0L6Qqyu9wNbuhadDi97FA0gnydrWTYYPB/w6QneLYJ8IBxTyTBdOuj5ej9s73YqKnxbcIp99GAZKV7I+PgP9fbCoaN9DpaI3/NOlc71gSZqWREIB7CtJ7BdPbAEw16NlZqNkEQqyy8MyixATg4bBs3ci8uqd5TbyANf6tAEFF9jULsR6MqAcBACOyD4peaoNZpbWBL02EtZyHBQyNQRAba381SDJAu+FMsDtDxmTTE4u9MexfOFD+2J9lMg/1C6mMWg5AIKReh8K91uA5RD8oXmqXNLnp5EgxN4A+9E3C+8FHmTSRlEdIMVwAYVz8b5cMkbUJoZe4LUNS8PpP7lwFrAe1TUyAyiqrpIwZX9/Cb+3NgIFWpcIfp6m64HcOjqmwIej1AD jDgCpBYq mg72cDxua4KilH1WrXkyDHhx5WAz1v0zECVuIC51UuolVX4VbNLsTCI3mlhb7oN+MbOGPtAeicqIg0FRW7ZB48EhB6hRNi0gEr21XIle4EiQfeT7JL1sTLhfB45z2TjJ5cdOoJneAhsdU8TEZvYK+s8ZWUDLk4SU76KCFlHTVV4iX9lR+njl8I/obUQNLfl/tOLQaDeCRst3b8DHI405vv/G0/7K+ChZlpjKI9z8v4dWGZjMOlZQWeagLWIkLsGGh6cFNlhWubfY+3+xCCl6JJAG+IzZ2RaoCPpSZ0QnLpt4xQD50WcyuJvwknIs/Ihmi3OOqwsRkFxxpSM1m6eJkbek+Mq6gCMIu0WOo 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 Tue, Jun 11, 2024 at 8:43=E2=80=AFAM Shakeel Butt wrote: > > On Thu, Mar 14, 2024 at 08:56:17PM GMT, Chuanhua Han wrote: > [...] > > > > > > So in the common case, swap-in will pull in the same size of folio as= was > > > swapped-out. Is that definitely the right policy for all folio sizes?= Certainly > > > it makes sense for "small" large folios (e.g. up to 64K IMHO). But I'= m not sure > > > it makes sense for 2M THP; As the size increases the chances of actua= lly needing > > > all of the folio reduces so chances are we are wasting IO. There are = similar > > > arguments for CoW, where we currently copy 1 page per fault - it prob= ably makes > > > sense to copy the whole folio up to a certain size. > > For 2M THP, IO overhead may not necessarily be large? :) > > 1.If 2M THP are continuously stored in the swap device, the IO > > overhead may not be very large (such as submitting bio with one > > bio_vec at a time). > > 2.If the process really needs this 2M data, one page-fault may perform > > much better than multiple. > > 3.For swap devices like zram,using 2M THP might also improve > > decompression efficiency. > > > > Sorry for late response, do we have any performance data backing the > above claims particularly for zswap/swap-on-zram cases? no need to say sorry. You are always welcome to give comments. this, combining with zram modification, not only improves compression ratio but also reduces CPU time significantly. you may find some data here[1]. granularity orig_data_size compr_data_size time(us) 4KiB-zstd 1048576000 246876055 50259962 64KiB-zstd 1048576000 199763892 18330605 On mobile devices, We tested the performance of swapin by running 100 iterations of swapping in 100MB of data ,and the results were as follows.the swapin speed increased by about 45%. time consumption of swapin(ms) lz4 4k 45274 lz4 64k 22942 zstdn 4k 85035 zstdn 64k 46558 [1] https://lore.kernel.org/linux-mm/20240327214816.31191-1-21cnbao@gmail.c= om/ Thanks Barry