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 B4DC5C25B76 for ; Tue, 11 Jun 2024 11:49:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3A9F6B0092; Tue, 11 Jun 2024 07:49:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EEA396B0098; Tue, 11 Jun 2024 07:49:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8B156B009B; Tue, 11 Jun 2024 07:49:34 -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 B91216B0092 for ; Tue, 11 Jun 2024 07:49:34 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 68DC7A24CD for ; Tue, 11 Jun 2024 11:49:34 +0000 (UTC) X-FDA: 82218437868.08.08DE9C6 Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 7D2CE20008 for ; Tue, 11 Jun 2024 11:49:32 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lMlZ3929; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718106572; 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=zM6sCCNyz3zbF+OseHVD84e8m7rxxZxvUuiGGqpJ9HQ=; b=Oo1na87jllhtoey+aW15qUm5Tom/GMUMkj/DkN3jJXOs8TrKIftuJfDh4s1Cxv1YLsb/AC z33aZ5rRG3Ewh5VvmU99iptpssmu6MPd9T8J55kOu3C1SUzXdM8UjItRyEsL3Wj+03AD78 VsqAnqIp80KqK5eVwd0ASXSugFNRLnQ= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lMlZ3929; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.222.172 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718106572; a=rsa-sha256; cv=none; b=GD3cj3k7qnFxHSDSmt1MKxd1BjpXm52BeLzYXeKCXWvinogdI9SdsfWCDV2AGdybohdTL/ vqIuXFQhAbM8Js3yCK1rTfh6hpHfqFF1kPD+9w74HFTh+iv/dU+w31shq4uCtwLRMI/A/c NuHqIIVA1L7lbSCk0JqG6V46P1VUxaY= Received: by mail-qk1-f172.google.com with SMTP id af79cd13be357-797e2834c4eso32100585a.0 for ; Tue, 11 Jun 2024 04:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718106571; x=1718711371; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=zM6sCCNyz3zbF+OseHVD84e8m7rxxZxvUuiGGqpJ9HQ=; b=lMlZ3929HzBAPVhn0HVIaEuq1e1J7f9YsRiPnDUTtsoPUsipllFRqblqMCuGmesBc5 Mmzs+PHypbzp9sFUVXLdR4PuEjgfGlx7rW7PcVvOiQHpAfiD6yaq8PLriLglfJ+D+jtL r994NY9WPPjK6eqJh+0/965mPTWq0wWrHi1zntbN8YXRAXU57LZ+2hXTefR07vvs3tae xGDBEP8UjsXD256Fmyyaa2DLpZqv7LSC5QFbvJWvZGWDWrFz4WqfHtjBuErt2IwN21/N Rf9TQbW1LdOlXBfSncwzf0PJBVVHHTG1g/9aICBRKwucAK2QgV2l0FTuq/mwzF3DKcpb upLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718106571; x=1718711371; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zM6sCCNyz3zbF+OseHVD84e8m7rxxZxvUuiGGqpJ9HQ=; b=iy7z7Bdlkd9C4Cw3A4kU8DBuFEyAr3p003u45h5CjcX9N1AerI6yDMBlLzo8opo4E2 rilsgMKsdLZH61p0oPyQCCRPTlqm4twURendcLsaCQpRHXv/9nCRidFxE9wLQ7ekwgZk xm+5Q+jNV0iBDvxA1TdJSATxli6+z0OQO+ebSkAnLPiw8ht5kICP5v2nX6pSamoOPW3S 7ckKfdaUPzsh6x+f5P/Cf40MNo2U2mFZ0c4El3Frl93//bktzRhwtH00G5i77bD29ogm I0P9YxQy146QH5gPtm9i0sQDe9UTn/hHy7FIbYunhcwZpp4FftqGAl0ln/efV58bYsAs 92uQ== X-Forwarded-Encrypted: i=1; AJvYcCV4J6xrwpnhSZK06NcySTcv+kN/tC84PTus/AdG6GnOlkoTH8wecNYYAf1Tqebrhhdij6MS1IpTomWZoG4O9LBt14E= X-Gm-Message-State: AOJu0YyWhPfVp/Zn1rBdGFhu5gD0FOok/IgPBVzuL4gPtaF3jEKD15UP cdlJ4FppCXH4QwgOsIlEodELu74ppF3i53JZYBIGDjUU5S6Ai+DU X-Google-Smtp-Source: AGHT+IFuaZm4PTedWMppwN/psDVDjWpYw00uONK9hGyy3bG0MxfKy7XPv6flRcWLbA6h3RpenoRhkQ== X-Received: by 2002:a05:620a:191a:b0:795:5de4:6625 with SMTP id af79cd13be357-797c2d6271emr434035585a.5.1718106571390; Tue, 11 Jun 2024 04:49:31 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:eb:d0d0:c7fd:c82c? ([2620:10d:c092:500::7:57b4]) by smtp.gmail.com with ESMTPSA id af79cd13be357-797ee6619ddsm17525485a.99.2024.06.11.04.49.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 Jun 2024 04:49:31 -0700 (PDT) Message-ID: <9ddfe544-636d-4638-ae0e-053674e47322@gmail.com> Date: Tue, 11 Jun 2024 12:49:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 1/2] mm: store zero pages to be swapped out in a bitmap To: Yosry Ahmed , 21cnbao@gmail.com Cc: 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, Shakeel Butt References: <20240610121820.328876-1-usamaarif642@gmail.com> <20240610121820.328876-2-usamaarif642@gmail.com> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 7D2CE20008 X-Stat-Signature: y6xr86t4xnyhzq8tnf76h4bjjp8ncayc X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1718106572-350052 X-HE-Meta: U2FsdGVkX193LuPZX328dxAKSIM9Prs6znOUMhma0lh+7BabE24aHa/fZjF5S3q2ZbcuYv2P3iffumUiIFa3vgez8P1Dkaa0iy69yENImGYAOdxYVroHtIgDvf90p6pZxLGGhUDUxv/0HdmUZUWKlYIUQd/U+FtTxC0hgHmM04L5V+e3pnkavd0KZKSlEyg8F7hpgkJxKIRqQZ03PTP/zcKvaXa2aIfDYbU/bq9VEJE6MGylk6c9h2TGrVK2l0EvC2heaDwNxW0vPglDjbOh8IMdMfkUEqfh4jJ6H58FYMy0KyJ78Tgu87RDLZMICjqkhs3myuXsd6jQwPFzfXsQS9QzcShTz2+TIdc6K6KVozadu/4QYcQP6hRmVWtbfZSu+Iz1TzARBAxeT2cxOhSHu9r6iwKJDJNUVqDncXBBBk7iloftsfRKcF4g6NkoRbpOq8UqF142MkMqAIpLARGtiHwTbNwRIomn4LPxyPWVdPF3bEStdJXWMrniFOo1TVOQxNGoaz/7HP7k6nOeMp2HuAbq3JwGx/Z7YxiTo+F0m2tYivRjOvs5z1iybMvRDyZPdbdXQmjqHCGUKh05xqHpiNRx/i+V+vMmYAmuzSr9U2RIFOe3nCZ8ImcS858IK514+ur8/JSwA/OFDZgBPsWXKHmRFQ0kDILkM4rR8v8ofyvLI6EHsQUuMlx4+KZmqvgPvP6wZSDRiHjD9usihEU12OeuadMA5hOzrobjLuu7PxyMzMt0mskQFarXSbUdaWA0YLmYOO4aMvkoJUbajw/iDjlLFuH5TeDFa4Q6jsP3AoplDVVVLrXL96mAwnWus0KBzQw9OUjZq4WTcqJJVLZANf2m/Or3qJiyhcOVOg+lK1HyOTh14hwG40HI7mOO8aiFEsQiGqKnw9ZanDYuK1KFwupkWHKvJIQ0pMel8CGozNTQB5qpmk75D2TKRFgBqS5wwv++xgsTF+kMsgY4BXm kFW1R/xt NDFp+BD3ZKYCtUL7oY6LxJR1OWfLuuYkc/Ltsak4QoQoU8NipH5EwCa2DTDc6041C4vj08VbmZnkgEgb5+Cy+ktnI5IE5gdpLud7spmG37/t6taMzzdwjT0V6k/810VczTEdvmK8zhfmearxModrSX15LGRDbjPfd3t72sJfI0BBwWsLNzYzu5rsqp9SLpROnkVd7tzrjNXDCdgTqIIR8T6CoC/9Lv1bTdpCz3inDbKaJ3ohZTeyWApGmgxNAZ8s3F2mQ9d2JDvwlRtXDJrtoAhAUjaz55pERol3VrSinoZW/Ude77qsqWQV94Bjp+5DB8n+1+8jThfLZHH6quzsDgGFmymK7Pr/gMS0Rrj2Z0EdfVnB/MHw4gOhVOIA8Xy5aRXfrNwviuRvKONffG75MyRaaaprpHkDWj3RMsmMB0xcbB1DnkudtkYF0ey5NbNUkYX5wKkOdIyotpym6ZELMLlTDdV92aQRqw71csCqa0mdPKQi52QbJTvWYQTNkibNmVyZhJDTWAGX5bZLbMs/k6iJjNBAR2cWRQn9cFMIwboU/ZJKKSrP2PAv5HgZCrs908MXvNVX1BBmYLHx8lna1CP6Tfg== 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: @@ -515,8 +600,11 @@ void swap_read_folio(struct folio *folio, bool synchronous, >>>> psi_memstall_enter(&pflags); >>>> } >>>> delayacct_swapin_start(); >>>> - >>>> - if (zswap_load(folio)) { >>>> + if (swap_zeromap_folio_test(folio)) { >>>> + folio_zero_fill(folio); >>>> + folio_mark_uptodate(folio); >>>> + folio_unlock(folio); >>> We don't currently support swapping in large folios, but it is a work >>> in progress, and this will break once we have it. >>> swap_zeromap_folio_test() will return false even if parts of the folio >>> are in fact zero-filled. Then, we will go read those from disk swap, >>> essentially corrupting data. >> So yes, with this patch I tested swap out of large zero folio, but when >> swapping in it was page by page. My assumption was that swap_read_folio >> (when support is added) would only pass a large folio that was earlier >> swapped out as a large folio. So if a zero filled large folio was >> swapped out, the zeromap will be set for all the pages in that folio, >> and at large folio swap in (when it is supported), it will see that all >> the bits in the zeromap for that folio are set, and will just >> folio_zero_fill. >> >> If even a single page in large folio has non-zero data then zeromap will >> not store it and it will go to either zswap or disk, and at read time as >> all the bits in zeromap are not set, it will still goto either zswap or >> disk, so I think this works? >> >> Is my assumption wrong that only large folios can be swapped in only if >> they were swapped out as large? I think this code works in that case. > I think the assumption is incorrect. I think we would just check if > contiguous PTEs have contiguous swap entries and swapin the folio as a > large folio in this case. It is likely that the swap entries are > contiguous because it was swapped out as a large folio, but I don't > think it's guaranteed. Yes, makes sense. Thanks for explaining this. > > For example, here is a patch that implements large swapin support for > the synchronous swapin case, and I think it just checks that the PTEs > have contiguous swap entries: > https://lore.kernel.org/linux-mm/20240304081348.197341-6-21cnbao@gmail.com/ > > This makes a lot of sense because otherwise you'd have to keep track > of how the folios were composed at the time of swapout, to be able to > swap the same folios back in. I think the solution to large folio swap-in for this optimization and zswap is not in swap_read_folio in this patch-series or any call further down the stack, as its too late by the time you reach here, but in Barrys' patch. This needs to happen much earlier when deciding the size of the folio at folio creation in alloc_swap_folio, after Barry checks     if (is_zswap_enabled())         goto fallback; once the order is decided, we would need to check the indexes in the zeromap array starting from swap_offset(entry) and ending at swap_offset(entry) + 2^order are set. If no bits are set, or all bits are set, then we allocate large folio. Otherwise, we goto fallback. I think its better to handle this in Barrys patch. I feel this series is close to its final state, i.e. the only diff I have for the next revision is below to remove start/end_writeback for zer_filled case. I will comment on Barrys patch once the I send out the next revision of this. diff --git a/mm/page_io.c b/mm/page_io.c index 2cac1e11fb85..08a3772ddcf7 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -274,9 +274,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)         if (is_folio_zero_filled(folio)) {                 swap_zeromap_folio_set(folio); -               folio_start_writeback(folio);                 folio_unlock(folio); -               folio_end_writeback(folio);                 return 0;         }         swap_zeromap_folio_clear(folio);