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 7968EC27C4F for ; Thu, 13 Jun 2024 22:41:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EDFCA6B00A7; Thu, 13 Jun 2024 18:41:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E8ED56B00A8; Thu, 13 Jun 2024 18:41:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D56706B00AA; Thu, 13 Jun 2024 18:41:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id B86666B00A7 for ; Thu, 13 Jun 2024 18:41:24 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 634D0160374 for ; Thu, 13 Jun 2024 22:41:24 +0000 (UTC) X-FDA: 82227338088.21.C6FB633 Received: from out-183.mta1.migadu.com (out-183.mta1.migadu.com [95.215.58.183]) by imf03.hostedemail.com (Postfix) with ESMTP id 39F4720007 for ; Thu, 13 Jun 2024 22:41:19 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=l4FAwlRB; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.183 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=1718318480; 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=axMkgrlRNzbazn3gKxpjsc5NsZWIHblTZHRj4tETIAI=; b=ljEpQfPTLbtT/XtBHbagc36GN+SOMOnE8oFYurbaKgdinj+ELJ6YnK9V39J2sjeQtkU4OC JZNs8yhPBTESoYBvbShkE7En/cI4frtVqb62ivxeodoOwZ4aZVDZVEi0We4b+KdE4aQQ2K uDbw3ba1GXC+nKFSV3DiPJUAa23aKPo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718318480; a=rsa-sha256; cv=none; b=yTw+e/7WqapYUYP+2LILDeH35jcSsG2ZTPG7bZtkLx5J5dxmZpHXr4pTlV4ACfASQRZ9S/ p1NL/v6haShQiPEUslNPjVgnI5Le/3fcwvlrF8waUyP5+Bf9Q3Uo4j9KlkFDZAxqgrpKnB 6VbhUNfgB903rqrFW+x0WhnXjls2JM8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=l4FAwlRB; spf=pass (imf03.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.183 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: yosryahmed@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718318476; 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=axMkgrlRNzbazn3gKxpjsc5NsZWIHblTZHRj4tETIAI=; b=l4FAwlRBM34rKqh9pvULsxJDfbGyY49ey30g82j5czLphMHWWYOvEx8+63TFPEa4Kagd9+ 8FSwfqQ0sKWjXYdyZ9yCQnRZnbovTskFfjE6UmX5bBO7cBG4cpj2G4UxDyafUeha+V5cDq bhpP9XDLntFqjrVc3NjJfq1mAA8SS2g= X-Envelope-To: usamaarif642@gmail.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: david@redhat.com X-Envelope-To: ying.huang@intel.com X-Envelope-To: hughd@google.com X-Envelope-To: willy@infradead.org X-Envelope-To: nphamcs@gmail.com X-Envelope-To: chengming.zhou@linux.dev X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: kernel-team@meta.com X-Envelope-To: minchan@kernel.org X-Envelope-To: senozhatsky@chromium.org Date: Thu, 13 Jun 2024 15:41:10 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Yosry Ahmed Cc: Usama Arif , akpm@linux-foundation.org, hannes@cmpxchg.org, david@redhat.com, ying.huang@intel.com, hughd@google.com, willy@infradead.org, nphamcs@gmail.com, chengming.zhou@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, Minchan Kim , Sergey Senozhatsky Subject: Re: [PATCH v3 0/2] mm: store zero pages to be swapped out in a bitmap Message-ID: References: <20240610121820.328876-1-usamaarif642@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-Rspamd-Queue-Id: 39F4720007 X-Stat-Signature: 7n6adp6ybe6fiz71n8da1n37pz9pwdgb X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1718318479-759590 X-HE-Meta: U2FsdGVkX18lIHcDM7tCd4GAMMK7Mj3C7CroOj9QNOGtvAdxUlmHOJ1HOUMj+x4X1EcBbfg+a3VnhHdo+3Hw7ao1lpqZYaPTsBOg2sW7/RDuj2PmAwVBTMnNavyfW9QO1uSSOM2aTuDfzXzmZcsYSJE2DuJQeHcomM9rIhrqHTDfYDG3J+0O9DvZ5Suu0Z04PpuloMYCD1SdILXhBdwYsKb8Ecg7v8XmH07PX1YbS53r4/OWDKw8DV/h/MVUtJ7RZ3PkzjWW621x732rJ35qy3PI2VkuIrpEpNADLEA4zwA/kfPuRlj9d5vOq1ODa9hAZxW24zQ8o/2ptuny1bCdQHrw0Zk82Y8rcW7Tf3nHANPK6cwDCvjA3RIXoOcWSQIGGtY0wV4WqaRgctw9lbsy+8LoC21c+oYZ+0vEHR5rA0sJTI9J/OvJHkYl5SesckxAuV2QxDP8rq+ZY11qcMNIjBdnvlk2E3CnGqbzGsrnW/+DlZO31vXu0bSHerOVP/4JY09D2z/ph9qbq7Bfy2PgNQM43gKKL+QlrENjN5wz7zowVwoRceCAhMYMAT/8598MAqZ7uentZelexfZ+lYqsLlqXn4lfUwKIA1X6RbojvV0R2T6pN1g+Wuz597Ws6C+RBsQM7XLi4y/VEOKePodmoUdHp9yL35bkhN7ubR8f9NnKCD6QSag8Oe5U3fXrsv3rGOA7GUD03C6wxVZplGbgiJTh4weDzEp9MdA85XBTtBCana820n3vm6+c+fs9W8uLkg6G76yUfHJvgVKENM6usswSKsubOGS8NRh/2689/fNePR2QWNuM9mSKt/qeUPhdoh7rvriRUtaDi/sgxBruGLnlCuPKSRFZkF1ap699Q5SDjf+fK7dNVRU1i45gfgAuh/LcaldwX1o42vcBykT03Rpg5Groc01Lq3JDIYq+DWqvUyy5I0Bcpr1Og8zouWtHE/axvbu7nKfyfev4xjA 2vR5vMW9 x8qHhsxJ4PPg3EQvtc7AL+L52Ze/7GMwgWZCCXa/UCAX7yoEzUkf/eNSH0jmPwFdf3bBivFhhMIwrhkuRVNYzlV3z9R+vvKhT75zOLr5kEnx+coJ2PKUOVDz7ieG66CLo24zUdkCBoZbJZZF0dfVjSL1PVOEKmi+2UMbPhLOtGn9KGfAYw72FMrxMaCBic9/6DzTMJAtdH5O3RD0= 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, Jun 13, 2024 at 02:50:31PM GMT, Yosry Ahmed wrote: > On Mon, Jun 10, 2024 at 5:18 AM Usama Arif wrote: > > > > Going back to the v1 implementation of the patchseries. The main reason > > is that a correct version of v2 implementation requires another rmap > > walk in shrink_folio_list to change the ptes from swap entry to zero pages to > > work (i.e. more CPU used) [1], is more complex to implement compared to v1 > > and is harder to verify correctness compared to v1, where everything is > > handled by swap. > > > > --- > > As shown in the patchseries that introduced the zswap same-filled > > optimization [2], 10-20% of the pages stored in zswap are same-filled. > > This is also observed across Meta's server fleet. > > By using VM counters in swap_writepage (not included in this > > patchseries) it was found that less than 1% of the same-filled > > pages to be swapped out are non-zero pages. > > > > For conventional swap setup (without zswap), rather than reading/writing > > these pages to flash resulting in increased I/O and flash wear, a bitmap > > can be used to mark these pages as zero at write time, and the pages can > > be filled at read time if the bit corresponding to the page is set. > > > > When using zswap with swap, this also means that a zswap_entry does not > > need to be allocated for zero filled pages resulting in memory savings > > which would offset the memory used for the bitmap. > > > > A similar attempt was made earlier in [3] where zswap would only track > > zero-filled pages instead of same-filled. > > This patchseries adds zero-filled pages optimization to swap > > (hence it can be used even if zswap is disabled) and removes the > > same-filled code from zswap (as only 1% of the same-filled pages are > > non-zero), simplifying code. > > There is also code to handle same-filled pages in zram, should we > remove this as well? It is worth noting that the handling in zram was > initially for zero-filled pages only, but it was extended to cover > same-filled pages as well by commit 8e19d540d107 ("zram: extend zero > pages to same element pages"). Apparently in a test on Android, about > 2.5% of the swapped out pages were non-zero same-filled pages. > > However, the leap from handling zero-filled pages to handling all > same-filled pages in zram wasn't a stretch. But now that zero-filled > pages handling in zram is redundant with this series, I wonder if it's > still worth keeping the same-filled pages handling. Please correct me if I am wrong but zram same-filled page handling is not just limited to swap-on-zram use-case and any zram as block device user can benefit from it. Also zram might not see any simplification similar to zswap in this patch series. I would say motivation behind zswap changes seems quite different from possible zram changes. I would recommed to evaluate these cases independently.