Received: by 2002:a05:7412:8598:b0:f9:33c2:5753 with SMTP id n24csp455212rdh; Tue, 19 Dec 2023 04:16:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IHeOl6KEyeYTfMHF0aGi8SyfZwa5iKxPEXA7WrVYPRFK5lHSWbWR1ICPdfzhRrsgk3i2rFX X-Received: by 2002:a05:6a21:328b:b0:184:da23:76b2 with SMTP id yt11-20020a056a21328b00b00184da2376b2mr23134128pzb.28.1702988186332; Tue, 19 Dec 2023 04:16:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702988186; cv=none; d=google.com; s=arc-20160816; b=CpiqQSdwhBf2MB+PGD5oomKuChVlxGRd4sgdeC2kz7EUkdlntr8VE+EIosWUBMGYf4 xVUetpjnP3cBD8qgVByPxIGwn4czlcMVy96AR7xFXcgS9Z2ldYA7Ofk4/DOHoU75lMI/ gBbVNoyl27YRHYQf0Cgv4oN/vjdSUNNp7mmxuUrl4ZQZxfpdzX3EJlebANRRY9BK5mnr zTh7FQi1rbIR9mWj2N8VtG++6SltrAB35gFwrPQ7sCVK9i5N+ojELFnf/MRchIOM2WUG /TyGtoU0nJE2mwRPgDBYoT8RTl4bizKUYLhjmTK47M7wymqNNxDquzr0a3Z7phnMQDbq JAow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=m5UnQ6ybd/a2078rBpVy5um9Db5Ao6jqQJgKdH3d4IQ=; fh=xnTRGDuPzIB8Y5YM825+6S2Lykr+8SnFtkB1xacOSwg=; b=Uq5DSzInBvcwDDnyEq74QJGYU0V+4Rs87EtR2hvI/VRGvqG+CRkP+C/rktehIoM+D0 WyODa8oS25225nMVyzIOdcwFz0eTNvJcMVf6EyA9HgOsETMJar0pxImHpYFYQDADey4Q nahxi5q9SOMXZLN8SPP9XioRnsMqmm76TBBkQ1gHcnqtwBN2Phibx1j3SoDnFBJCJSTa vHC5Yt2tOUG5iap7W68A1AR1CXG4I9Rp7EvMpzj4T0RTaQcT8m+6cTeUSuQwfyCKYYH/ ImG0dC0d7xWuq/TLIz/DfsIVkP3WIzJX7UTQCcTXYDfDK2Aq4Qpwx7nA9tJtmtDGVJs9 kupw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance.com header.s=google header.b=jfIK5QVz; spf=pass (google.com: domain of linux-kernel+bounces-5151-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5151-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=bytedance.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id x2-20020a62fb02000000b006ce91f9ff99si8426574pfm.42.2023.12.19.04.16.26 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 04:16:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-5151-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance.com header.s=google header.b=jfIK5QVz; spf=pass (google.com: domain of linux-kernel+bounces-5151-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5151-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=bytedance.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id EFCE0283B59 for ; Tue, 19 Dec 2023 12:16:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 01F7418E20; Tue, 19 Dec 2023 12:16:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="jfIK5QVz" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3F2E18E15 for ; Tue, 19 Dec 2023 12:16:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-28ade227850so3361893a91.2 for ; Tue, 19 Dec 2023 04:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1702988176; x=1703592976; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=m5UnQ6ybd/a2078rBpVy5um9Db5Ao6jqQJgKdH3d4IQ=; b=jfIK5QVzcNp+WtaqhQoUnyLGDBm2qf6Cht1Vueyk6ioW5E74D9/KOqBd+kYftGN3cU 1ORLaNn2PU+cRYJLs+LIDxiJCrJgRGSoTrsu4wOq71zvdjwbPj8FPO95A1/qSTzH0BiD /vYeV5qtJysBu2j3kWgjU5xw01Ar87QLH4zqm8ziAjbExJCTAFKJU0jm1xQglUAyfiPb R6wFqt+DadY3GYNfjTpLsNFQ3SImWkn4Ady4YclKKDqbnJ6ZwIpC4cmzDKgx2qf4BioZ LyW/dS5dx5eonXw5ipZTOo/cDF0yd+oJDeYb0uGuInQjcBv1Fi0BZJ/C2w6Qc9OckBgO PWKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702988176; x=1703592976; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=m5UnQ6ybd/a2078rBpVy5um9Db5Ao6jqQJgKdH3d4IQ=; b=IzUrjNWZRX6UrAwFEveGhVKv0Mmt/g9tcW6vw6kgFHZJQnze3ZswHlep+fZk7ZRW5o ePL5h1nfsfYsc0AwxcyDtlUXIllnpzP1+M30rV3o/Oy0m07OH0GVqsLiaRiWe4hHy/1D E7Pf+41VLdHfMaVXmNDTrGpUXV4l4J7szERP4pY5iw1DnY/LTXJaATMM0E4/IJa2hR3U DYvVwUQVOjsg3Iid5ILL8SWl2+mHdzet7gUjuzcN1+SXaPOcIztI2SptEmpV4jyza7v4 nqybaE1Oxcl2ozy3FhkHykTs3CURxz8aSh+B541ZXnizoQCHeJGzKJ9sCK+R9iLlAim5 KFMg== X-Gm-Message-State: AOJu0Ywj1+NcRvsKyLCOWX3FSIrMFMh3JyDKEP+O8bxNgLIKbUIzQLwG rnI+w4iqNxy7zzL6DFw6erIXxg== X-Received: by 2002:a17:90a:ee93:b0:28b:b87d:6661 with SMTP id i19-20020a17090aee9300b0028bb87d6661mr745170pjz.92.1702988176097; Tue, 19 Dec 2023 04:16:16 -0800 (PST) Received: from [10.254.3.151] ([139.177.225.245]) by smtp.gmail.com with ESMTPSA id ne19-20020a17090b375300b0028bc2e66f06sm509509pjb.54.2023.12.19.04.16.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Dec 2023 04:16:15 -0800 (PST) Message-ID: <62bcf150-08ee-41e8-be77-57ef3bac116d@bytedance.com> Date: Tue, 19 Dec 2023 20:16:08 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 5/5] mm/zswap: cleanup zswap_reclaim_entry() Content-Language: en-US To: Yosry Ahmed , Johannes Weiner Cc: Andrew Morton , Nhat Pham , Chris Li , Seth Jennings , Dan Streetman , Vitaly Wool , linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20231213-zswap-dstmem-v1-0-896763369d04@bytedance.com> <20231213-zswap-dstmem-v1-5-896763369d04@bytedance.com> <20231214142320.f5cf319e619dbb2127c423e9@linux-foundation.org> <20231218140313.GA19167@cmpxchg.org> <20231218145815.GA21073@cmpxchg.org> From: Chengming Zhou In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 2023/12/19 04:52, Yosry Ahmed wrote: > On Mon, Dec 18, 2023 at 6:58 AM Johannes Weiner wrote: >> >> On Mon, Dec 18, 2023 at 06:39:13AM -0800, Yosry Ahmed wrote: >>> On Mon, Dec 18, 2023 at 6:03 AM Johannes Weiner wrote: >>>> >>>> On Thu, Dec 14, 2023 at 02:41:26PM -0800, Yosry Ahmed wrote: >>>>> On Thu, Dec 14, 2023 at 2:23 PM Andrew Morton wrote: >>>>>> >>>>>> On Wed, 13 Dec 2023 17:02:25 -0800 Yosry Ahmed wrote: >>>>>> >>>>>>> On Tue, Dec 12, 2023 at 8:18 PM Chengming Zhou >>>>>>> wrote: >>>>>>>> >>>>>>>> Also after the common decompress part goes to __zswap_load(), we can >>>>>>>> cleanup the zswap_reclaim_entry() a little. >>>>>>> >>>>>>> I think you mean zswap_writeback_entry(), same for the commit title. >>>>>> >>>>>> I updated my copy of the changelog, thanks. >>>>>> >>>>>>>> - /* >>>>>>>> - * If we get here because the page is already in swapcache, a >>>>>>>> - * load may be happening concurrently. It is safe and okay to >>>>>>>> - * not free the entry. It is also okay to return !0. >>>>>>>> - */ >>>>>>> >>>>>>> This comment should be moved above the failure check of >>>>>>> __read_swap_cache_async() above, not completely removed. >>>>>> >>>>>> This? >>>>> >>>>> Yes, thanks a lot. Although I think a new version is needed anyway to >>>>> address other comments. >>>>> >>>>>> >>>>>> --- a/mm/zswap.c~mm-zswap-cleanup-zswap_reclaim_entry-fix >>>>>> +++ a/mm/zswap.c >>>>>> @@ -1457,8 +1457,14 @@ static int zswap_writeback_entry(struct >>>>>> mpol = get_task_policy(current); >>>>>> page = __read_swap_cache_async(swpentry, GFP_KERNEL, mpol, >>>>>> NO_INTERLEAVE_INDEX, &page_was_allocated, true); >>>>>> - if (!page) >>>>>> + if (!page) { >>>>>> + /* >>>>>> + * If we get here because the page is already in swapcache, a >>>>>> + * load may be happening concurrently. It is safe and okay to >>>>>> + * not free the entry. It is also okay to return !0. >>>>>> + */ >>>>>> return -ENOMEM; >>>>>> + } >>>>>> >>>>>> /* Found an existing page, we raced with load/swapin */ >>>>>> if (!page_was_allocated) { >>>> >>>> That's the wrong branch, no? >>>> >>>> !page -> -ENOMEM >>>> >>>> page && !page_was_allocated -> already in swapcache >>> >>> Ah yes, my bad. >>> >>>> >>>> Personally, I don't really get the comment. What does it mean that >>>> it's "okay" not to free the entry? There is a put, which may or may >>>> not free the entry if somebody else is using it. Is it explaining how >>>> lifetime works for refcounted objects? I'm similarly confused by the >>>> "it's okay" to return non-zero. What is that trying to convey? >>>> >>>> Deletion seemed like the right choice here, IMO ;) >>> >>> It's not the clearest of comments for sure. I think it is just trying >>> to say that it is okay not to write back the entry from zswap and to >>> fail, because the caller will just try another page. I did not like >>> silently deleting the comment during the refactoring. How about >>> rewriting it to something like: >>> >>> /* >>> * If we get here because the page is already in the swapcache, a >>> * load may be happening concurrently. Skip this page, the caller >>> * will move on to a different page. >>> */ >> >> Well there is this one already on the branch: >> >> /* Found an existing page, we raced with load/swapin */ >> >> which covers the first half. The unspoken assumption there is that >> writeback is an operation for an aged out page, while swapin means the >> age just got reset to 0. Maybe it makes sense to elaborate on that? > > How about the following diff? This applies on top of Andrew's fix: > Reviewed-by: Chengming Zhou The latest v3 also put the comments on the wrong branch, and this diff could be folded to fix it. v3: https://lore.kernel.org/all/20231213-zswap-dstmem-v3-5-4eac09b94ece@bytedance.com/ > diff --git a/mm/zswap.c b/mm/zswap.c > index e8f8f47596dae..8228a0b370979 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1458,15 +1458,14 @@ static int zswap_writeback_entry(struct > zswap_entry *entry, > page = __read_swap_cache_async(swpentry, GFP_KERNEL, mpol, > NO_INTERLEAVE_INDEX, &page_was_allocated, true); > if (!page) { > - /* > - * If we get here because the page is already in swapcache, a > - * load may be happening concurrently. It is safe and okay to > - * not free the entry. It is also okay to return !0. > - */ > return -ENOMEM; > } > > - /* Found an existing page, we raced with load/swapin */ > + /* > + * Found an existing page, we raced with load/swapin. We generally > + * writeback cold pages from zswap, and swapin means the page just > + * became hot. Skip this page and let the caller find another one. > + */ > if (!page_was_allocated) { > put_page(page); > return -EEXIST;