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 E73C6C27C65 for ; Tue, 11 Jun 2024 17:24:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 699E56B009A; Tue, 11 Jun 2024 13:24:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 649096B009C; Tue, 11 Jun 2024 13:24:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E9DE6B009D; Tue, 11 Jun 2024 13:24:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 301B56B009A for ; Tue, 11 Jun 2024 13:24:30 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D10E3C14DB for ; Tue, 11 Jun 2024 17:24:29 +0000 (UTC) X-FDA: 82219281858.25.499AA08 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) by imf08.hostedemail.com (Postfix) with ESMTP id D6B9B160004 for ; Tue, 11 Jun 2024 17:24:26 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=a1K7XLgu; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.182 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=1718126667; 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=O3i+HyGj1VKoyFoBY2yyUEOXBAoTrzIHET6FO3GGsZo=; b=RXvf+aWNWR+ykfLZFgq2ENc6Sn9n3KQvl9hn9RdsoKjson9zKzSFC4OhOVXGswpo/DuWiW 14pFsbHSU20M4x1qc+nJkOQ/5aGsO49l93hWE6uD3nVVd62IXu0kcDHk0wZgD4kO1AKiug 88q4PyA/Ss2uoDT0gG7AelSGcfMue4s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718126667; a=rsa-sha256; cv=none; b=jMYzMdf9GfFMCf3fZxJs1CiXpz6HSler9FPS2qFHVFm3nTY5lCZfRceG7wIx6VT42cx51A b6rdgjk6u2jrP1uZZUyfu4APDreDNvCng67fOPKicSNE0YY9mRR2QIm2JrvIVG8iyIJ/GH E4xLjcgMlAwVlLxmrJCykZO/fgVA+Ow= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=a1K7XLgu; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.182 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: 21cnbao@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718126664; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O3i+HyGj1VKoyFoBY2yyUEOXBAoTrzIHET6FO3GGsZo=; b=a1K7XLguZyWpGyUG7DGAmh39NzH9EnD1KN/l95PsIonEde1btPH7252Kez+WyPEoOOyhQU lAfFrulkQDP3bEbnBWCrQqMGir699/jG8fvNiFJ4yFPTcgZXkEVUyEKDHhuTtUimd8NukZ DgdqVZUqTYAey9eBl6sq8TOOfo3YYpg= X-Envelope-To: chuanhuahan@gmail.com X-Envelope-To: ryan.roberts@arm.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: Tue, 11 Jun 2024 10:24:17 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Barry Song <21cnbao@gmail.com> 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 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: fg4rzutepdkaa8hx4t3dinbjtxo1ge4a X-Rspamd-Queue-Id: D6B9B160004 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1718126666-287184 X-HE-Meta: U2FsdGVkX1/j6MgtWf9jwaP7j5Ijy27Q2BHh4TX/pJRYcNWWok8wM9/bnINXdD2PX66fSq3QPYiqhtU5DgSMPiJN91Hoapy7NszILKMB0W4a2ZudBo9nAc/akVUPavpQCm9AVsTTwi2gKViRPjDXXphelCbvGMHHInoAQKKeHfsENtcoq96c+auQiY2KZgSyfaLVwuvIRjnQZbVSYbxymw/1gG/XffbeYv8xB7qh/3BqISNw57wjxixlyFlv89+mvHIMCUPEfjC8feI63WXLcxiBZCxh2TINv1HM0GSnmO5+owWy3tdP+6fDQG7ByPpy4usK08pbC4qexywJljXBSpml+bXnOMd6hDGX54sIzek5rUvee3mlG8xTHq1haFFTCygNOxEK3Zca2FKyBu/12jxGchuMOPJ/LBo7YBgNuAJQg0BcOYghH6LWBaCYy6H4XxYfsWGAAmaMPQVSAXeEyUq42VCTgHFOxYFyk77cLSSyMzY5HLqvXHuEoRpvENfyQUtF9CX3bMdun0sEgAZC1cx4BM8g9pebZ00TW7p5XkQY9cqJzdHhJUAInHoflej048vlkJAZjO+zBjdavXyEzT2u0rgI8whxfnzP8QhN+SNqYI235uPlZsjDWrGGIwlPonrYthZ8tTa0UFo/+uxe1FY8gecqq0v7XFtA09hDkRprvTqkrBarwx9pcfcPPNacfK5x2QHqLe1DJFbBCF8K7hbOQ+Wt6lq3VXt02RP2L8mKwXHRV1L0aPjhaUWeQD1S1p4vZD3pxO8QEFFVGjnNMgXQDjy+vnvqS2mWFOJFK04NaTkVswG9cKonZmZwwcXdKPfX3BxVdJTtxetAxM2h08STStHt8KLIT4h0qavPi4r1KGkILUimxPoTraeqAI5vz7Iw7sc/tZBi8MlV6svSpWKihhRraBPBG0426MCtxryi/3m2QeuxKGnF+u+bYlEbba8vMeK9Db8fVNWKG+O q2lCzk5B aQ0O3qAMCC7KN9z5eoifs8IPS1k2fF2k6qX+3GO3AqnheDj5aZtoITYbcOFkdwniH8KN9PoPCIW0fFy8UshYsaJ5JYx3ityD0a44HDJ11SVa7nDv8umf/YC6x/3+GzEMbR+mZS9i/1TYCrc6FvDj22IjzATZn6jN5o9jIfnaCx4oGcVdJVXV8uJPxGDF9GqaWonPoJWYOX5NOTIs= 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, Jun 11, 2024 at 12:23:41PM GMT, Barry Song wrote: > On Tue, Jun 11, 2024 at 8:43 AM 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 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? > > 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 Thanks for the response. Above numbers are actually very fascinating and counter intuitive (at least to me). Do you also have numbers for 2MiB THP? I am assuming 64k is the right balance between too small or too large. Did you experiment on server machines as well? > > [1] https://lore.kernel.org/linux-mm/20240327214816.31191-1-21cnbao@gmail.com/ > > Thanks > Barry