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 C350EC47258 for ; Thu, 25 Jan 2024 09:27:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1CFC46B009B; Thu, 25 Jan 2024 04:27:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17F936B009D; Thu, 25 Jan 2024 04:27:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 047166B00A8; Thu, 25 Jan 2024 04:27:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id EAB156B009B for ; Thu, 25 Jan 2024 04:27:35 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id B692A1C17BF for ; Thu, 25 Jan 2024 09:27:35 +0000 (UTC) X-FDA: 81717305670.24.85B2479 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf10.hostedemail.com (Postfix) with ESMTP id C9A18C0008 for ; Thu, 25 Jan 2024 09:27:33 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fQ+XcncZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706174853; 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=jxu9V88yZ4UG+aRX+313RxWb5ML+i/iwlaR54KeMD+s=; b=iVdY4Zv8fJiSziMS1CETmZgxGIpdfnuZVBnxZHHCiuRaszdiOQk8A0JJoHksVeMbmGsClh o8Cg1h5PuuIJqDXQFYBIPIKVKwSI3Q7eE7+MKuev1FLHu0zeuLGsFSS58e95joU8iXCo8X v1dCbaIEaaFnWaK/S/XOi3XOiQB4CKc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fQ+XcncZ; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706174853; a=rsa-sha256; cv=none; b=zLbnPK9o66y/skRaMgdMbq0DYPgwKnG04yW35uPTyOvia7BxbE1NHubn7A6D2Qs8w3ymb4 uJY1ok/ZbRbLuVL3bCryN5Zz8QcK9uSyl4B6cRIPTpAr/FZL+jpqRTXA5D7Ivb8NzDoRZh J81NdWjqKUdXjTLEsAJ7kXaytpaEDFk= Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-558f523c072so7709414a12.2 for ; Thu, 25 Jan 2024 01:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706174852; x=1706779652; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jxu9V88yZ4UG+aRX+313RxWb5ML+i/iwlaR54KeMD+s=; b=fQ+XcncZ2N6dVHHPmU2Gt2ZWCQuI/jAhxjzJwC8wGob71Qy6SsqSDeNkKveK+bYP2y 0kuz8Zqh9HlJobp45ul6IuD/0GYjW62WquEIVVuCGGUksVe2Cofs7oygKhAnnFLi2YnY jlZv4uwSq7CEsfbi+1IOOf4EyAX+3AbLWktfHH24NUzXJUplf2qqpXr/l0PnWbdOkQx8 WXanNwBg/QgbXHWFz4En9TKi3YLYzdIO3SzyG8/yXjFTFzeT+/bX0Hrdk2sHIy6Rfmu8 dWjBJSeSkqfKRxnJFz9lgEEmh+P03zIjvJm8lQlkQ79+PjdVCuP+pfLIdHfBiN0fi0Rt RShQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706174852; x=1706779652; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jxu9V88yZ4UG+aRX+313RxWb5ML+i/iwlaR54KeMD+s=; b=QSU1nW1zaAcpO7hn0VUKk2KVKlzlGoCYr9dpZjyvo+Y2jg6h3oj8XPPIiGguOz4jPg 1NldByWIHk7K4km535q7gMlMYcrpBUEe14mOX4ym3R+OgJ4TXrEbgw5fLaWxHQ6Adx6j UE7UWixxuM2TaLhjNwJqDRsUO40w0imTNexs6sSb3dC2rg6JcB/sHHFZ1kifsFQdYZM0 R1Do6A0SL6UsZJkFtJBUdQh68dgqJOlRR+9Ziyr8+i9x73hdi7ldkBOW9g1Dp/g8AtKI umdJhYr1QEK4wg4rkoX0acn1y7KcuCBG7jKZW+nCYgRUeThrcxtQ9qpnbuOHngbn248C +n2Q== X-Gm-Message-State: AOJu0YwQ0zKdYMXv+2fpx+8dJxfoObVV35Tdpqt99eJ84W4Vud/wDuLq rwUcwwTVwDyRLt/QutAihxhbg40D47UUIsEuQ6z9HAm8olFgB3voVKD/VSrDaRJiEcQq7AAT/Lw 1t4dth4iE1AwYei4iVhixc49thCexxKwHRlPo X-Google-Smtp-Source: AGHT+IHbGQaeXi5No/2WNrUVDS8iMvqeU07IVEV094Noq1vLvOQCbf1UJl4TTMMDDGyNMp2P8E1fyOD057RP4WlyE1I= X-Received: by 2002:a17:906:c056:b0:a30:deb6:1bb7 with SMTP id bm22-20020a170906c05600b00a30deb61bb7mr211283ejb.132.1706174852166; Thu, 25 Jan 2024 01:27:32 -0800 (PST) MIME-Version: 1.0 References: <20240120024007.2850671-1-yosryahmed@google.com> <20240120024007.2850671-3-yosryahmed@google.com> <20240122201906.GA1567330@cmpxchg.org> <20240123153851.GA1745986@cmpxchg.org> <20240123201234.GC1745986@cmpxchg.org> <1496dce3-a4bb-4ccf-92d6-701a45b67da3@bytedance.com> <35c3b0e5-a5eb-44b2-aa7d-3167f4603c73@bytedance.com> <1a8a513f-fa84-41ca-b7f4-62726e78fd31@bytedance.com> In-Reply-To: <1a8a513f-fa84-41ca-b7f4-62726e78fd31@bytedance.com> From: Yosry Ahmed Date: Thu, 25 Jan 2024 01:26:56 -0800 Message-ID: Subject: Re: [PATCH 2/2] mm: zswap: remove unnecessary tree cleanups in zswap_swapoff() To: Chengming Zhou Cc: Johannes Weiner , Andrew Morton , Nhat Pham , Chris Li , Huang Ying , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C9A18C0008 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: idi6xosh6eszrmiju91i5t6agje4gbga X-HE-Tag: 1706174853-894337 X-HE-Meta: U2FsdGVkX1/sceGkBG0rqd0v1T+F+m2etcP9mTGSXwK6iDBBKC9CpvF0np+Ag7ifsH2QzydbX6AwqsEBbtaw4KGDarNwOJalhWB1jAWCPEmDqOkzVDzOip6F3D5SGeZHCfjdjlveSXQdqm9a6fjcB9c/F60lLl1AihOob5i81516kqa+JHIMWBibAFJrveHersIsC7qsDYrSQG5JnvcKMHTITMA3zVOFHrNOZcR1kpuDH3HKmP9IFKy9LNdarsca6HbcYtPpTYluVUd/uLz6JPAr4xvHZHh+mX5QzI9pUfIX2ZfHijmVDdbV04obpRcbK8TwQcEeCtkBizE0lbau45M5nFbOfytkUO5QML4w8+9710KpDAdEy/JeKooA6+NMTxgOSQeiLtZ15pv1WF5VdnbbcOx0nQOcQtHdBy47jy8k5Dp2zAerirIJlzryy66tjiHh7O/AiaFNsRjKzl8DkAmLKriVQuDo39eN6nDDisaGZwnCWAo7oQxIHi8unUQOl7AIuqZBTaXZBEUtgDyASyOOag/22E/fnvnWiT0Gqk/h0zUI8TkS3fSK+HDrDOP5NEuWoFMQ9A8ZfYVMBYlta3voih9OE9zB3EsF5u/WuM5p5TOWATXY02I3y3RVNZfp7b0+UTlwYx66Ed3tTk0ykPc7i7fC34knTjBLXme2GWKQnskWQ44E5EKUZ8iQXze6ahhgdSkjINVAgyFZBjEtH1ca9/RXjQmHRcDM1NKIuDoOklO2TycxZhYYu0HRysfNC99Ohji9CJRkdQdNjxg0JNEqQLVZhvgY7b25872OVdUJjRNxp38VCzyGN5XHAhKvyZ56CcyGZC6Cz7D75IPayxUd48NZ+l/dsWnD3CHH4Noqg0iQzK6ojwOvhBxXEDMQOM7naSJaYJJtQNQX7MnVmK+o1Gw6crYvm79QB6pdNLuY0pXnsPNmzSU561EBQyTwpmOd4imhuRsyN9SziRf +/w5I4gk yYrDkR5T9CHRLzAoQDsgA27RHSn+9Zu4Hlv1YrBiJd7YHLciTUmj3FN0stR56ebivSX0++Sx1T1f/bDkS9qFHSTi4m4TUL8JfA5pv8MaOFgRQA0A7czK8FqLC5q7vr5xVN6JZE8THJSiGuKuWc3GpPTyAK0jGdnQGSPQrsdKkycf1ekCTrtj6Zkfm9HTJhGVl+TmXKlZsr+dtaTQ42rYzztFWTgixCl+R7xf7xmdmaZ3CyoMgEq2c6pXelhSDAg48WY/28/UCtU7MrhtC25QYXtLm2L09Q5Wn8sxlk7Ql7NQXsmZWozqcFjrVy71QQaLHlYWX7EMBi0ZACh4= 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, Jan 25, 2024 at 1:22=E2=80=AFAM Chengming Zhou wrote: > > On 2024/1/25 17:03, Yosry Ahmed wrote: > >>>>>> The second difference is the handling of lru entry, which is easy = that we > >>>>>> just zswap_lru_del() in tree lock. > >>>>> > >>>>> Why do we need zswap_lru_del() at all? We should have already isola= ted > >>>>> the entry at that point IIUC. > >>>> > >>>> I was thinking how to handle the "zswap_lru_putback()" if not writeb= ack, > >>>> in which case we can't use the entry actually since we haven't got r= eference > >>>> of it. So we can don't isolate at the entry, and only zswap_lru_del(= ) when > >>>> we are going to writeback actually. > >>> > >>> Why not just call zswap_lru_putback() before we unlock the folio? > >> > >> When early return because __read_swap_cache_async() return NULL or !fo= lio_was_allocated, > >> we don't have a locked folio yet. The entry maybe invalidated and free= d concurrently. > > > > Oh, that path, right. > > > > If we don't isolate the entry straightaway, concurrent reclaimers will > > see the same entry, call __read_swap_cache_async(), find the folio > > already in the swapcache and stop shrinking. This is because usually > > this means we are racing with swapin and hitting the warmer part of > > the zswap LRU. > > > > I am not sure if this would matter in practice, maybe Nhat knows > > better. Perhaps we can rotate the entry in the LRU before calling > > __read_swap_cache_async() to minimize the chances of such a race? Or > > we can serialize the calls to __read_swap_cache_async() but this may > > be an overkill. > > Also, not sure, rotate the entry maybe good IMHO since we will zswap_lru_= del() > once we checked the invalidate race. Not sure what you mean. If we rotate first, we won't have anything to do in the failure case (if the folio is not locked). We will have to do zswap_lru_del() if actually writeback, yes, but in this case no synchronization is needed because the folio is locked, right?