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 021AEC27C55 for ; Mon, 10 Jun 2024 20:43:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2CDF26B0089; Mon, 10 Jun 2024 16:43:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27BFD6B008A; Mon, 10 Jun 2024 16:43:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 144736B0092; Mon, 10 Jun 2024 16:43:27 -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 EB64C6B0089 for ; Mon, 10 Jun 2024 16:43:26 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 4B49580760 for ; Mon, 10 Jun 2024 20:43:26 +0000 (UTC) X-FDA: 82216154412.04.841953F Received: from out-186.mta1.migadu.com (out-186.mta1.migadu.com [95.215.58.186]) by imf16.hostedemail.com (Postfix) with ESMTP id 55F3A180006 for ; Mon, 10 Jun 2024 20:43:21 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=o565Ppp0; spf=pass (imf16.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718052203; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+atSc5zHsdMS0skjiFYlGfZpkjkkMKe1giRVAcA2SE0=; b=bBH5ftCxtgEXs87HducnjFUvzfKvS/brYFP9AnNvQXlZAUFzGLDJuxL05NOGOmzjfHLo9f PdkDU6SPyh0ZS7Oktbzq3amN7yopsyWzaSJ3kpuhejMn2Qe1djLws6+RTqswhmlJuxwPKO x0TVKyK2MQR9SV6Rjhpg1OP082xg/9o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718052203; a=rsa-sha256; cv=none; b=5EXvoglNByK9FYzryTH7MAad0tc1NXqWcC6n/e7Kved35n8Rx6WRp5NKFspn9OTsM3akfS 2ACxZ2AzpCrhuprhuQMW8a5s2aRbDdTA2JHGyBWuYrL9gmkiYuQbqLNe7KKz+ZbTuL9BUL sltXUEgKBf3sqHx28cIRNpghhTzMfnk= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=o565Ppp0; spf=pass (imf16.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.186 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: chuanhuahan@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718052197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=+atSc5zHsdMS0skjiFYlGfZpkjkkMKe1giRVAcA2SE0=; b=o565Ppp0gWCACnhv8ESr1bs0XryAs2JpPECDn+zeH7cv8Y+bVxreEv0E8eURQe3Qv6JsX+ m3koFtxPElpQ9dJMDGjY5CDZoK2rHNwU/qUrKwS/okv7e7b+HW3Dh29fEkAyCAh0Qz5DHz LjXcYdheOkIX04Ndje9avI8J0pETnM0= X-Envelope-To: ryan.roberts@arm.com X-Envelope-To: 21cnbao@gmail.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: chengming.zhou@linux.dev X-Envelope-To: chrisl@kernel.org X-Envelope-To: david@redhat.com X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: kasong@tencent.com X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: mhocko@suse.com X-Envelope-To: nphamcs@gmail.com X-Envelope-To: shy828301@gmail.com X-Envelope-To: steven.price@arm.com X-Envelope-To: surenb@google.com X-Envelope-To: wangkefeng.wang@huawei.com X-Envelope-To: willy@infradead.org X-Envelope-To: xiang@kernel.org X-Envelope-To: ying.huang@intel.com X-Envelope-To: yosryahmed@google.com X-Envelope-To: yuzhao@google.com X-Envelope-To: hanchuanhua@oppo.com X-Envelope-To: v-songbaohua@oppo.com Date: Mon, 10 Jun 2024 13:43:10 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Chuanhua Han Cc: Ryan Roberts , Barry Song <21cnbao@gmail.com>, 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 Subject: Re: [RFC PATCH v3 5/5] mm: support large folios swapin as a whole Message-ID: References: <20240304081348.197341-1-21cnbao@gmail.com> <20240304081348.197341-6-21cnbao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: 96rwy6k87wbhh71ek99frkge5outjyto X-Rspamd-Queue-Id: 55F3A180006 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1718052201-190263 X-HE-Meta: U2FsdGVkX1/k1ZrWkPZ+NcG6h/g5ccB7BXuNVbmtHFSwXeC8tW2ouWrSKuNGyUf51TDQsHLmN8ZLVIO5sV0Vr2LuseR0dju5yW32fAX/ZE/MUdbN0duftbBlg4T2bMxyqBCaJQja9ObFbSZNDnHCq/bxa7sjlQ1iboo1yyQowzQSjU3sFfpOQ+MqJ0SOHIAfXWwGBuSIZi5FSvpKoqwFZNGuWF1P1+IFvi9fNmm+Vjyy3e+NKU+ZWx9r0t2LnVUoWBREZMark6P5V4u8oA7aBUvGaNejVNqY7lcAxBKJKR08fwx3qhm6tnFrDF+IzxVnTtoxy8SPVVm1NOJpVI+hSlZtUi5QaeC+EXzKapjNZFEByKp4rYlMt5ZlcwaRYXUmkDSYdLg4Snl/1ZGZhCZyGSX4JKzH/O1O9zqyJKz/+teJlQop6nAlpAXagb396MBFNRW5NcXsG5qeGsYSSbDZ1s5KLrar2/fhvCyncXTOY0BZ/RfD0MLr0m/sjRiS2szP5dec3JvuexOo1Eo6TJDTOd2aglHw14WPscNGTRU077vgeMG692fDyzZGXuB5ak0KAlWlmnb7czQBph/K948WLyRU7tEVc01LaWZ9nIRyxm7t1uwIyJmqNwa+eLzhbOdmS3SOkN8dzzfLQhbGTf9ngtk8qujTgJWhF6J0cSuFZxgYEeYoXdaQzmCJLireQvAlHrskiIr4kqf1ul/vv/qIeqhn0C2SQvfHojauxtSGTLRofW1w00B6kIKeC1kykpDvcggiLm4YH63nSfGfhsjdVOegEBJsjMd86thPKJREgZSVJqeG4hws7sIvu7HTC7nfOMMq5d3jSP/A0Zafdfhtz9dOx9xvXB5OSVfu6vpXyPULHo+bq7+b+48SMF41N3owkeKFBF2SOCUzy5l+DYj8RVQiFc0PpizVWdSkG/S5+AXaaMV5LHjX+yRLzDVN+RuTElV2+QEoJ4ULxFmGs7s IDAwgbRk h16Zp7F0wLqeHPIqWK2vL4CKy6FQ0yiGjuwutZig2UBXus9Ut/MyK+xU19KGSh331REIPTQeZTXDdZJNf3E0IPOuvlw== 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 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 actually 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 probably 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?