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 5372ECF9C69 for ; Mon, 23 Sep 2024 12:10:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0D806B007B; Mon, 23 Sep 2024 08:10:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BDE96B0083; Mon, 23 Sep 2024 08:10:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85EBE6B0085; Mon, 23 Sep 2024 08:10:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 69C1A6B007B for ; Mon, 23 Sep 2024 08:10:51 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E3EACAC349 for ; Mon, 23 Sep 2024 12:10:50 +0000 (UTC) X-FDA: 82595886660.24.ED899EC Received: from mail-qk1-f181.google.com (mail-qk1-f181.google.com [209.85.222.181]) by imf29.hostedemail.com (Postfix) with ESMTP id 8BF4412001F for ; Mon, 23 Sep 2024 12:10:48 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=3JosB2Y8; spf=pass (imf29.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.181 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727093388; a=rsa-sha256; cv=none; b=LrIM21MlAEKxn9YBjt+dNIB62OOK9UqjVC0iBd5fm7at8BPFsFp2nVUDF1GE1P1y1yHNv/ PzaUHiB/4ubEPzPxBcGDvvJbbAjJrgUKFlVdX0agds42Wp7KDkZcpScxEi0TTOWbxeo4Pc fUKoK4bWLJ7u4s1bpstc2YjpeyJsJhw= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=3JosB2Y8; spf=pass (imf29.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.181 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727093388; 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=rRfOQ0tS9cN4A6dE8SfP42PhT4ARLrBFORewUNU1yeg=; b=Js1XES8Ev/UXovLkFCAr1SH6WjXFZ6bCz6fvtoM9JGsU8PbHgzRbLAwK2m6GU0OBIGqeEk jSIN+s/AELVIa+oVHa01UEYLkvQB54LydJvRaN1/gAZQiNRwlJt9vT//mtcpK3Las1htgr uRx+aXZH7XGVwTRqKKo05grMPd+5148= Received: by mail-qk1-f181.google.com with SMTP id af79cd13be357-7a9acc6f22dso443378285a.0 for ; Mon, 23 Sep 2024 05:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1727093447; x=1727698247; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=rRfOQ0tS9cN4A6dE8SfP42PhT4ARLrBFORewUNU1yeg=; b=3JosB2Y8HjTPQrgnkZQR1zab+JwY30vc9xG3xb4WCiGBAk98iKIr1vP9gCH2ilvCI4 tf9U3fAhIweIzzKCNpR82fRoAlGhTGArZjlPqYPBP2PKPAzvzG1q+U2CvuhP7P5tAcS/ 72um/uI5dTcMTWKGiEOUtriR/46L5dKF3tZ+FHJQWs38t6kTETvk9HzGvKf8MHd0zDyK 6PJIlx/ykiLRwBSQHix28FqTttsIC+AHZKo1gkeYuZcupCI+AyXt+GQuIsHYq/sN5zJm O4KAM6WUbDfv5N206Z++vWD+JQUYwCm2N28PrrxR3evEaSSIIGo4NHEJzhxDwF3rgoPL SQCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727093447; x=1727698247; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rRfOQ0tS9cN4A6dE8SfP42PhT4ARLrBFORewUNU1yeg=; b=u8SROqVKlKnhbpVMQIFkzKaxdxwmOqGCPAn+HquDhi8C6rJRWvQ9OiXmnu+w5zcnVp p9HjyV4+5u2XGympSXYbd8fz9xDR09fgjV37Ppt6Ro/+e2Kotbag2rDLykfVWZ6qsN7e /crIPiskyHdLTub9Gs/OC0FjwoB8ACZeUfNOxACwdf8ABDbyLZrmec0FV91rETn3f0UN x4R1LoBqTUh/OQpzNvUH5qQQ7NDinvyWLNQBbZzkxhlBrn1nriBgJnf4IQqfOaKBjoEB NQYXWBShJTN/jBS1gOBWqmLw+YOb6Ed735nwgLLoCWzQaz3FOLJXWHAkOoqZ4ivQCJ2u tUWw== X-Forwarded-Encrypted: i=1; AJvYcCWXY2arD06HrOPY9oUHJlyrfrR+rGgvMnC/3y1o2ro05St89PsMBDCq1EznaOnYwsiWkPTQvjvfsA==@kvack.org X-Gm-Message-State: AOJu0YyJEASIB0tyHorSthgLmdQGRLWinb+Nm775JfXP+6T3wz+J+XGK 0hhVH00QBfIHBZ1hHLarq3gGCCDGWmHWO1Q8weA9sKnIAHl0EWkdV59WYiE5luk= X-Google-Smtp-Source: AGHT+IElg8qVKPTj4Pd2rDhN1S71xp00EUK4UYGmT5pMHGR/us3IeiPIoyDuGeqQZi3Ydh6nJDM7Aw== X-Received: by 2002:a05:620a:450a:b0:7a6:5a80:7ee7 with SMTP id af79cd13be357-7acb8209cd4mr2158460385a.46.1727093447388; Mon, 23 Sep 2024 05:10:47 -0700 (PDT) Received: from localhost ([2603:7000:c01:2716:da5e:d3ff:fee7:26e7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7acb08ed0bdsm470264885a.130.2024.09.23.05.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Sep 2024 05:10:46 -0700 (PDT) Date: Mon, 23 Sep 2024 08:10:41 -0400 From: Johannes Weiner To: Usama Arif Cc: Barry Song <21cnbao@gmail.com>, Yosry Ahmed , Andrew Morton , Kairui Song , hanchuanhua@oppo.com, linux-mm@kvack.org, baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hughd@google.com, kaleshsingh@google.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, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, hch@infradead.org, Hailong Liu Subject: Re: [PATCH v7 2/2] mm: support large folios swap-in for sync io devices Message-ID: <20240923121041.GB437832@cmpxchg.org> References: <20240903130757.f584c73f356c03617a2c8804@linux-foundation.org> <94eb70cd-b508-42ef-b5d2-acc29e22eb0e@gmail.com> <2c418b81-8f67-4a45-b4d2-d158fa4f05d9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2c418b81-8f67-4a45-b4d2-d158fa4f05d9@gmail.com> X-Stat-Signature: rxk49r9uhm1mddwdn3pd13mbffoohhdo X-Rspamd-Queue-Id: 8BF4412001F X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727093448-466600 X-HE-Meta: U2FsdGVkX1/DBKCQ6JbiFvkC/iQFQB17JzjRjWitRwo8QoV0mfw5UAQ34Lj3sI2tXTF1diezGTMXVtb0Qw+fNLSri8KaUd2XVuRtVRG0BpxGkBH/ZZFjgrvJGIyWfahkfVvEGQjO/JOI5Nh2frhhsRyItZuoJJ6Qz4v4qDqUyO3+FdkkA2DHUm3ZRwYpTE7dLynh/Tno7JiQWR6kIKJSuMEI61yJ9U9/BJlY8+Ed3LjUwihl6HqmE0Gf7rTsGEqYuQaZeHt3oc17q1pIhJ3198vXqHX7WPM4zosXV4SWCLWt6r/hmBuqKfnedpfF0XSztnWG2m+8GXJ/XvcIJutEGnpKrIMQpu1auNGYeZNgt50azURgz6Pl8E72vk2efI63kgFDI4ofLRIfUsi1Y0JfYg6F23U9QDLwBK6UkemGZ7xNShIVNZ2r3V/pac3M1hgFQSe9rtTEBmcDOlKaJnY3F9yL5QSyEYk6IRENCy/lZRMpWyFEiKaxyddm5i4VqLEfb05XZGNule5+bO6jGjo2/S3OPZz8qilweUwB7OMiwh2kQ943IrboWCHPzrEomsXqY5Tzb2RUX9aulIfueqO+AwU/LrhFpjf6JbFVbI100d9uvkkgFX4RlY3h2EmgwfdewdM9CFlY8bgriWF9mTCUf8VQwDTDk6BqY7AHVVV8tucbqWeKEjIzVQS7YmJvyqLYoxvqL8iqEkvO/TEvbR/373T3iRkbYaeiFzJODvtXVyJCLvdQuJ3EZCKWI0E+sBzNxNkFGw+g9GRvChxR9xpELniBEJ035DfmaOyMrz14jeiM7hGwLkI6CEKveLQ/a8Wz3vopWHcI39gdd1RFH6wwLpumIoBJ2P4Z2Zq2c091K52Gu3sQP6HpX73URBbyspePEsivMNpiEUliEdap0XecysLnfiLPjeW9S7BzkGJ57cwnWLkxrdCE61VRsJZ+AVgUQ0+9bzld1RnBkTquzsz gy9dGR5S S0jnFZsW0WMUAl9bUY5E9Ud1g39wNB9NXkXO5v7+fZ9tc9ccjqcUjuBMn41CLBjA8wIClZWDPrLLuU3NF73W5d5HmAhuppS+Y1GifsG84Ro29zQbAhfd86ssNPTh0dFNS1HTQILVXkzbMqFUbHfodOAvyMbRD4iQ4BInbtwf52k5MorQWah8C5mfGhZArYY4JYRgKhL75ign3JS6T1SqVQXAVhj8bhTZWSiuDSZrTNoCKRoG5BKSQH3eA+BPohvUZ4ZyMG/OhQk9Y3AjGrflAyLvELtoC1mcLajvNGPLuODsVn8EbsmXqBHHPL1gABVF0YV5HVtdN9S+kqjGIC8qNVBVPUGOoddwv6KZvWJ3SIyDyGTwP0OLpSH+TIUf369dN+52mx1SAGr0ZlUbFR7i6nBo3OTnuoKmOb3W1mg2372veTZ2ygZuha79HUqWCF82qWlIdTCrP5C2U90X3RY/Lsv5wpT4pO4BMXp9KR8HOj6dzi9oBOHbO7MnOoq8wQxvJnMNN9CM3Tg4xjf7LJAz0GEvds/8IqYlsIkUZqik6DGPncBBxLCe6aCrTwQ== 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 Mon, Sep 23, 2024 at 11:22:30AM +0100, Usama Arif wrote: > On 23/09/2024 00:57, Barry Song wrote: > > On Thu, Sep 5, 2024 at 7:36 AM Yosry Ahmed wrote: > >>>> On the other hand, if you read the code of zRAM, you will find zRAM has > >>>> exactly the same mechanism as zeromap but zRAM can even do more > >>>> by same_pages filled. since zRAM does the job in swapfile layer, there > >>>> is no this kind of consistency issue like zeromap. > >>>> > >>>> So I feel for zRAM case, we don't need zeromap at all as there are duplicated > >>>> efforts while I really appreciate your job which can benefit all swapfiles. > >>>> i mean, zRAM has the ability to check "zero"(and also non-zero but same > >>>> content). after zeromap checks zeromap, zRAM will check again: > >>>> > >>> > >>> Yes, so there is a reason for having the zeromap patches, which I have outlined > >>> in the coverletter. > >>> > >>> https://lore.kernel.org/all/20240627105730.3110705-1-usamaarif642@gmail.com/ > >>> > >>> There are usecases where zswap/zram might not be used in production. > >>> We can reduce I/O and flash wear in those cases by a large amount. > >>> > >>> Also running in Meta production, we found that the number of non-zero filled > >>> complete pages were less than 1%, so essentially its only the zero-filled pages > >>> that matter. > >>> > >>> I believe after zeromap, it might be a good idea to remove the page_same_filled > >>> check from zram code? Its not really a problem if its kept as well as I dont > >>> believe any zero-filled pages should reach zram_write_page? > >> > >> I brought this up before and Sergey pointed out that zram is sometimes > >> used as a block device without swap, and that use case would benefit > >> from having this handling in zram. That being said, I have no idea how > >> many people care about this specific scenario. > > > > Hi Usama/Yosry, > > > > We successfully gathered page_same_filled data for zram on Android. > > Interestingly, > > our findings differ from yours on zswap. > > > > Hailong discovered that around 85-86% of the page_same_filled data > > consists of zeros, > > while about 15% are non-zero. We suspect that on Android or similar > > systems, some > > graphics or media data might be duplicated at times, such as a red > > block displayed > > on the screen. > > > > Does this suggest that page_same_filled could still provide some > > benefits in zram > > cases? > > Hi Barry, > > Thanks for the data, its very interesting to know this from mobile side. > Eventhough its not 99% that I observed, I do feel 85% is still quite high. Would it be possible to benchmark Android with zram only optimizing zero pages? diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index c3d245617083..f6ded491fd00 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -211,6 +211,9 @@ static bool page_same_filled(void *ptr, unsigned long *element) page = (unsigned long *)ptr; val = page[0]; + if (val) + return false; + if (val != page[last_pos]) return false; My take is that, if this is worth optimizing for, then it's probably worth optimizing for in the generic swap layer too. It makes sense to maintain feature parity if we one day want Android to work with zswap. > The 2 main reasons for the patcheset to store zero pages to be > swapped out in a bitmap were for applications that use swap but > not zswap/zram (reducing I/O and flash wear), and simplifying zswap > code. It also meant fewer zswap_entry structs in memory which would > offset the memory usage by bitmap. > > Yosry mentioned that Sergey pointed out that zram is sometimes > used as a block device without swap, and that use case would benefit > from having this handling in zram. Will that case also not go through > swap_writepage and therefore be takencare of by swap_info_struct->zeromap? No, it won't. However, the write bios sent from swap have REQ_SWAP set. Zram could make its same-filled optimization conditional on that flag if it wants to maintain it for the raw block device use case.